Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment Re:Buy American? (Score 1) 182

Unless you grovelled quite carefully over every new batch of virus signatures and heuristics(not necessarily a good idea if it delays protection against viruses that could already be hitting your gullible users; and not necessarily an easy task, if the number of occasions when an AV vendor has accidentally broken the OS or some common program by misidentifying it as a virus is anything to go by); even a fully 'non-malicious' antivirus program could turn very unpleasant very fast with the wrong update.

Be a real pity if some parts of your PKCS 11 stuff generated some false positives and the 'sample submissions' happened to include key material, no?

Comment Re:Buy American? (Score 2, Interesting) 182

It isn't just AV outfits. I don't know how much arm-twisting this originally may have involved; but Microsoft will let suitably qualified government customers look at the code. Given that the people who don't respect your copyrights have access to pirated versions anyway; and you don't really want "Security" to be an automatic winning argument against using your product, I imagine that it's not too hard a case to make.

What I wonder more about is how much this access actually helps those who have it. Antivirus products in particular, and reasonably complex software in general, receive vendor updates that can, and sometimes do, substantially alter their behavior quite frequently(and often in response to serious security holes, so you can't just adopt a blanket policy of sitting on all updates for 18 months); so if you want to stick to the carefully hand-reviewed stuff, you'll be so far out of date that random botnets and commercially motivated attackers will be nibbling on you; but if you want timely signature updates and security patches you essentially end up trusting the vendor to not slip something nasty into some urgent auto-update.

Comment Re:Can't do math (Score 4, Insightful) 605

This case is particularly unimpressive; but I suspect that the sheriff isn't thinking hard enough about it. Mortality in the late teens to early 20s related to doing really stupid things to impress your peers isn't exactly something that was invented at the same time as smartphone selfies.

"Cars and alcohol", "pointless fights", and "things not to do in flooded quarries" are more common variants than "youtube stunts"; but unless the sheriff's social circle is really small, he probably doesn't even have to imagine; odds are pretty good that someone he went to school with, or was otherwise close enough to have heard about, died while taking really stupid risks for attention. It's not that uncommon.

Comment Deagle noobs... (Score 1) 605

This seems like a terrible idea even if books were a great deal more hardback than they actually are: even if the book resists penetration, it doesn't magically annihilate the kinetic energy involved; just spreads it over a somewhat larger area.

Taking ~2,000j to a small rectangular region of your chest(while offering better odds than taking the same amount of energy directly from the bullet) does not sound like a good time. You might just break rib or two; but there's lot of important soft tissue there: heart, lungs, major blood vessels.

Comment Re:When it's not an open platform, it'll probably (Score 2) 95

Which might actually have been a dire warning for the people at Intel behind the Galileo and Edison devices: Both were x86; but violated enough legacy-PC expectations that the OS(es, did anyone aside from Intel's Linux branch get interested?) had to be ported; and any of the old 'basically uses DOS as an RTOS by ignoring it for time critical stuff' x86 applications were unlikely to work; plus reports on the quality of the documentation range from 'frustrating' to 'dire'.

386s, by contrast, are markedly slower; but are pretty exhaustively documented and supported at this point; and their behavior hasn't changed in ages, so your expensive legacy software and/or system design doesn't have to either.

These offerings were too novel to just inherit support by carefully copying a prior design(or at least its software facing behavior); didn't have a solid attempt to compensate for that with quality support and documentation; and once those factors dragged it down into the morass of eccentric SoCs with slightly shaky Linux BSPs, just being able to run x86 code in userspace applications wasn't enough of an advantage to offset the relatively high price and areas of mediocrity(reasonably high speed GPIO, in particular, was...not impressive).

They might have actually done better if they had offered a 'DOSbox SoC' or something that, from the software side, slavishly replicated the behavior of a Pentium Pro and whatever chipset was most popular in a single chip, just faster. Instead, they broke with the past far enough to require a fair amount of support; then didn't provide it; which doesn't exactly command a premium price among random application processor SoCs.

Comment The Joule is an interesting kill. (Score 1) 95

I am a trifle surprised to see the Joule among the dead.
The others were hopeless: too cut down(in terms of 'IBM PC' stuff), for x86 compatibility to be of much use, notably lousy at GPIO twiddling compared to microcontrollers or devices like the TI ARM part in the Beaglebone; but at least they were expensive!

The 'Joule', though was a stock Atom part, plus some RAM, Flash, and a NIC in a little computer on module. Not based on some weirdo part; and allowed you to drop a more or less standard Atom based system into something without consuming much space. I'd be curious to know if it died because existing SoM vendors do it better, and Intel decided to stop flailing around and upsetting them; or because lack of interest in x86 for anything that doesn't either involve a small off the shelf motherboard(for onceoffs) or 10 zillion custom motherboards (for laptops and such) is just that dismal.

Comment Re:It would have been for an elite (Score 1) 263

Even with the schedule that was actually used; cellphones went through a fair period of being rather pricey "I'm-basically-Gordon-Gekko" status symbols that tended to indicate either nontrivial disposable income or a job where being able to contact you on short notice was worth a lot of money to someone.

Given the vastly more limited options(both for handsets and for making efficient use of spectrum) in 1947, I find it rather hard to imagine how such phones would have been anything but stratospherically expensive. TV is kind of a festering wasteland of a use; but getting broadcast to work well for as many users as can afford receivers is vastly easier than getting transceivers working for more than a modest number of users in a given area

Plus, we don't have to speculate: the US had MTS in 1946; and it was indeed both expensive and capable of supporting only a small number of users because most of the cool tricks for spectrum sharing were either not developed or known in principle but not feasible to implement on real hardware.

Comment And the ugly trick is... (Score 1) 348

This is one of those situations where the 'best practices' both look bad and are hard to get rid of because they(often) are the locally optimal approach in a situation that is unlikely to go well.

If you follow those "best practices"; you are basically doing what you can to act like a contract or outsourced IT service provider despite being an internal unit. If that's the best relationship the department can have with the rest of the company, yeah, odds are that it isn't going to go all that well. Best case, you'll be an efficient and largely inoffensive closer of tickets and deliverer of legalistic written-to-spec 'solutions'; worst cases go down from there.

However, unless you really are dreadful at this; odds are that the IT department is acting like an external contract break/fix shop because the rest of the organization views them as one; more or less irrelevant unless something has stopped the email from flowing or a specific buzzword needs implementing. Organizations that view IT as a basically homogeneous support mechanism for the status quo probably aren't going to be doing anything terribly elegant with it; but not because they are hamstrung by IT billing for helpdesk time; but because they don't really want to have IT, except the bare minimum required to keep stuff from being broken all the time.

Slashdot Top Deals

Staff meeting in the conference room in 3 minutes.

Working...