"Some mobile equipment, such as laptops, netbooks, and tablets, are stored in a special 'high-value' area behind a chain-link fence thatâ(TM)s been erected within the warehouse itself."
Prediction: Multi-million dollar tablet heist within 6 months.
That fence isn't there to keep you or me out. The walls and doors of the building do that. (Presumably. I haven't been to NewEgg's warehouses myself.)
The fence is to protect the products from employees and other staffers already in the building. Only the more trust-worthy employees can get into the cage. The minimum-wage semi-transient workers are kept out. It's a fairly common technique -- most retail stores do something similar. Certain items (typically small, high-value, and popular) are frequent targets of employee theft, and that's where that stuff goes.
... Brown Squares And Blowed Up Trucks, http://tinyurl.com/86tx2e5... a white splash mark in the middle...
The white splash mark looks like a dispersal pattern originating from the center point, as would be caused by wind or blast from the other side. In keeping with the artillery target theory, it could be some kind of marker to measure the force or blast characteristics of an explosion.
IANAPIA (I Am Not A Photo Intelligence Analyst), so don't take this as proof of anything.
There is an unbroken chain of compatibility from the latest AMD processors back to the 8008...
Of course, no discussion about Intel vs AMD compatibility would be complete without some jerk* remarking that with x86-64, Intel is actually cloning AMD's 64-bit extensions to x86. One of the more ironic twists in that race, to be sure.
You make some interesting and insightful points. I don't have time for a proper reply, and likely won't before the story closes, so I just wanted to say that you made me stop and consider, at least.:)
The system did not exist until 1997, so it is highly unlikely it was tested (intentionally or not) in 1971.
I guess you missed this part, which I'll repeat here for your benefit: "It was so long ago that the system's changed completely, so the results aren't valid today anyway."
And it's worth pointing out that human factors play a large role in most failures, and we're still using the same Mark I Human, as far as I know.
Apparently, the system has been tested like this at least once before, albeit accidentally. (And it was so long ago that the system's changed completely, so the results aren't valid today anyway, but work with me here.)
The story is, on 20 Feb 1971, some operator at NORAD loaded the wrong tape, and instead of the desired test message, an actual Kiss Your Ass Goodbye message was sent out. Perhaps not surprisingly, most of the stations dropped the ball and didn't act on it until after a cancellation had been sent.
Later, when we were 17, 2 other couples joined my (different)girlfriend and I and we all had sex with each other in my friend's attic while her father slept downstairs.... That girl and I later used her parents' VHS camcorder to record our porno onto an old Teenage Mutant Ninja Turtles cassette... We watched it once, then drove out to the country and broke it before throwing it into a lake.
Dude, that's disgusting. Where are your morals? I mean, really. Polluting a lake like that.
Security? Why would that even appear on the radar?
Computer security has been an issue since at least the 1960s, and it's been well-documented and understood since at least the 1980s (when the NSA Rainbow Books appeared). The Morris worm hit in 1988. None of this stuff should have come as a surprise, and there were many people talking about how Microsoft was repeating all the mistakes over and over again.
As you say, the fact is, Microsoft wasn't concerned with security. I don't give them a free pass for that. The entire world has been paying for their mistakes ever since. Their lackadaisical attitude towards security -- when they certainly could have learned from the literature and from history -- has cost the world billions, if not trillions of dollars.
Windows, Mac iOS, and Android all have the concept of an application directory where all the files for an app go.
This is perfectly possible on *nix, too. There's nothing magic about any part of the filesystem. As long as the shell can find your executables, and the loader can find your libraries, it will run. But it's not as smart as it sounds.
A great many libraries are used by more than one executable, package, or even family of packages. Where do those libraries go? They don't belong to any particular application. I suppose you could have a different directory for each library package, but what does that get us? Thousands of directories with a handful of library files in each? What's the advantage of that?
Separating files by their intended purpose, the way traditional *nix does, has some advantages. For example, by having executables separate from libraries, the system spends less time searching inapplicable files when you invoke a command name. By having platform-independent files under/usr/share/, one can have share that tree across architectures. Not needed on a traditional personal computer, but in a "cloud computing" design with multiple platforms coming into use on demand, it's quite useful.
I suspect the "one directory per package" mentality is largely driven by the closed-source world, where code sharing is rare, and software tends to be isolated. In the Free/Open Software world, it's very common for many different authors to both provide and make use of others' libraries and resources. Diving things into "products" doesn't make nearly as much sense there.
As a result, any old fool can publish an app in the Android Market with 1/10th the experience and skill required to be in Debian.
Debian (and most other distributions) have rather higher standards of quality. You have to do things like provide documentation, declare your dependencies on shared libraries, etc. This makes the system work better. It does mean "any fool" can't get their software into the distribution. But why would I want software written by a fool? Badly written software causes me pain.
maybe we should instead dump all of an applications files into shared directories, where they can clobber each other
It's the job of the package manager to keep things from clobbering each other, and it generally does a pretty good job. Anything installed on a system can potentially effect that system -- simply using different directories won't make that problem go away. That's why package managers exist in the first place.
Merging/lib and/usr/lib?
I think the/usr vs root distinction is less relevant than it used to be (what with even tiny computers having huge storage), but I do still think there's benefit to keeping a minimal but useful subset that can be used to fix the rest of the system. MS Windows has to use a "recovery environment" for that. I much prefer the idea that the rescue system can just be a smaller portion of the main system. Sure, sometimes it will be totally hosed and you need to boot from some other media, but plenty of times it's just that a more complicated subsystem has gotten broken, and it's nice to be able to fix that in-place.
They address that by saying "There is no way to reliably bring up a modern system with an empty/usr, there are two alternatives to fix it: copy/usr back to the rootfs or use an initramfs which can hide the split-off from the system."
Of course, they conveniently omit the third option: Fix their init system so it doesn't depend on half the software ever written just to bring up a basic system.
Unix wins because it follows KISS. Fedora (and others) have been moving away from that. It's not good.
Given the prevalence of libraries being used by more than one program, trying to organize things into directories-per-program doesn't make a whole lot of sense to me. You'd really need to have a different directories for each package. So now you've got thousands of package folders, each with a handful of files. What does that get us?
I think the idea of keeping track of what files belong to what package is the job of the package manager, not the filesystem layout.
As a historical note, "coder" used to be a separate job role from "programmer". Programmers wrote programs. On paper. Coders had the job of translating the program into machine code and entering it on the card punch. An early assembly-language system was dubbed "auto-coder" for that reason.
(There's some similarity here with how "computer" used to be a job description as well.)
I'm not sure it's even possible to create software that does *the same thing* as a discreet circuit
That would be quite easy. It's the opposite way that's often impossible. Problems that can be easily solved in software are often too complex to solve in hardware.
Software which *includes* (proper superset) the features of a discrete control solution is easy, sure. But software that does *the same thing* as a discrete control (mutually inclusive)? Not so much. Certainly if you're programming anything fancier than a fairly simple microcontroller, you're going to start doing a lot more things that weren't happening before.
Complexity breeds failure. Complex software doing complex things is going to be less reliable than simple solutions doing simple things. If you want a robust system, design many small parts doing simple things, and strive for high cohesion and low coupling. That way, when the system running the catalytic converter tuning fails, the cruise control is completely unaffected.
That does mean you don't get to have a single computer controlling every aspect of the car, though. Higher costs and less sexy.
In fact, discreet circuits are theoretically harder to test than software that does the same thing and certainly harder to debug.
People like you scare me.
I'm not sure it's even possible to create software that does *the same thing* as a discreet circuit. If it is possible, it's never done in practice. Software invariably does more. (Trivial example: Memory management.) And that is where the problem lies.
Discrete controls will be assigned to one task and one task only (because making them do more makes the problem more complex, and thus involves more work). In practice, this makes them easier to test and debug.
Software will be assigned multiple tasks, for reasons unknown, but probably related to misguided thinking similar to the parent poster's. This still makes the problem more complex, but for some reason complexity in software is regarded as "feature rich".
"This is a test. This is only a test. If this had been an actual emergency, you would have been writhing on the ground in unspeakable pain, bleeding from every orifice, while your skin peeled off in long, black, ragged strips. This was only a test." (Unknown)
What I find more interesting is they posted an email address which they claim goes to the person who screwed up. It's obviously an alias created for the occasion, but it still might actually go to that person. If it does, that shows a measure of accountability that is almost unheard of these days.
Of course, it might also just go to the bitbucket.
The airlines won't treat their customers with malice and disrespect.
HAH! Have you ever flown before?:)
The TSA is easily the worst of two evils, but airlines are notorious for their poor customer service. The big difference, of course, being that you can usually choose a different airline.
Somewhere in China there's a factory that makes the internals for ALL cheap printers and depending on incoming orders puts them in a slightly different case and slaps a different sticker on the box.
While there are some shared laser print engines, I've also seen quite a bit of differentiation.
For example, Espon's inkjets don't appear to share much of anything with HP. The carriage is a very different design, the paper feed mechanism is a different layout, the control software has nothing in common, and the drivers are night-and-day different. HP's drivers are hundreds of megabytes and buggier than Maine in June; Epson's are 3-5 MB and are well-behaved.
Or compare HP's laser printers with Lexmark. Lexmark uses a two-piece design for consumables (separate toner and photodrum), while HP uses a single cartridge for both. Again, HP's driver is bloated and unstable; Lexmark's is compact and unobtrusive.
Now, they might well all be assembled in the same factory in Malaysia, but if so, it's out of different parts.
There are toner page counters in the high-end stuff. It's how the consumables monitoring/reporting works, and that's good to have. It's just the printer firmware doesn't refuse to work once the page count exceeds the rated life.
While I can't speak to the parent poster, I can say it varies by engine, body style and transmission type. The turbo models obviously use more fuel. The hatchback and the sedan aren't always comparable (depending on the model year). The manual transmission is better than the conventional automatic, and the CVT is better than either.
In my 2010 Impreza 2.5i hatchback w/ manual trans, I get around 28 MPG real-world, and I drive like a maniac. If I drive for fuel efficiency I can easily make 34 MPG. The CVT can supposedly come close to 40 MPG. 49 seems high to me but he might be in a different market that has different engines. (Maybe there's a diesel somewhere.)
The real news here is that this shows just how poorly conceived this idea was, and a real lack of planning and vision at the top. Not good. Netflix must really be feeling the heat from the studios -- not to mention competition -- to be flailing about like this.
Slashdot Mirror
"Some mobile equipment, such as laptops, netbooks, and tablets, are stored in a special 'high-value' area behind a chain-link fence thatâ(TM)s been erected within the warehouse itself."
Prediction: Multi-million dollar tablet heist within 6 months.
That fence isn't there to keep you or me out. The walls and doors of the building do that. (Presumably. I haven't been to NewEgg's warehouses myself.)
The fence is to protect the products from employees and other staffers already in the building. Only the more trust-worthy employees can get into the cage. The minimum-wage semi-transient workers are kept out. It's a fairly common technique -- most retail stores do something similar. Certain items (typically small, high-value, and popular) are frequent targets of employee theft, and that's where that stuff goes.
... Brown Squares And Blowed Up Trucks, http://tinyurl.com/86tx2e5 ... a white splash mark in the middle ...
The white splash mark looks like a dispersal pattern originating from the center point, as would be caused by wind or blast from the other side. In keeping with the artillery target theory, it could be some kind of marker to measure the force or blast characteristics of an explosion.
IANAPIA (I Am Not A Photo Intelligence Analyst), so don't take this as proof of anything.
There is an unbroken chain of compatibility from the latest AMD processors back to the 8008...
Of course, no discussion about Intel vs AMD compatibility would be complete without some jerk* remarking that with x86-64, Intel is actually cloning AMD's 64-bit extensions to x86. One of the more ironic twists in that race, to be sure.
* Today's jerk being played by DragonHawk
Look for a correlation with massive avian die-offs.
And if you see Dominic Monaghan, run.
You make some interesting and insightful points. I don't have time for a proper reply, and likely won't before the story closes, so I just wanted to say that you made me stop and consider, at least. :)
The system did not exist until 1997, so it is highly unlikely it was tested (intentionally or not) in 1971.
I guess you missed this part, which I'll repeat here for your benefit: "It was so long ago that the system's changed completely, so the results aren't valid today anyway."
And it's worth pointing out that human factors play a large role in most failures, and we're still using the same Mark I Human, as far as I know.
Apparently, the system has been tested like this at least once before, albeit accidentally. (And it was so long ago that the system's changed completely, so the results aren't valid today anyway, but work with me here.)
The story is, on 20 Feb 1971, some operator at NORAD loaded the wrong tape, and instead of the desired test message, an actual Kiss Your Ass Goodbye message was sent out. Perhaps not surprisingly, most of the stations dropped the ball and didn't act on it until after a cancellation had been sent.
http://stlradio.net/pages/ebsaccident.htm
Above web page contains scans of the old-school Teletype messages.
Isn't there a limit where it becomes harassment?
Sure! Just call the police and...
Oh.
Later, when we were 17, 2 other couples joined my (different)girlfriend and I and we all had sex with each other in my friend's attic while her father slept downstairs. ... That girl and I later used her parents' VHS camcorder to record our porno onto an old Teenage Mutant Ninja Turtles cassette ... We watched it once, then drove out to the country and broke it before throwing it into a lake.
Dude, that's disgusting. Where are your morals? I mean, really. Polluting a lake like that.
Security? Why would that even appear on the radar?
Computer security has been an issue since at least the 1960s, and it's been well-documented and understood since at least the 1980s (when the NSA Rainbow Books appeared). The Morris worm hit in 1988. None of this stuff should have come as a surprise, and there were many people talking about how Microsoft was repeating all the mistakes over and over again.
As you say, the fact is, Microsoft wasn't concerned with security. I don't give them a free pass for that. The entire world has been paying for their mistakes ever since. Their lackadaisical attitude towards security -- when they certainly could have learned from the literature and from history -- has cost the world billions, if not trillions of dollars.
Not okay.
Windows, Mac iOS, and Android all have the concept of an application directory where all the files for an app go.
This is perfectly possible on *nix, too. There's nothing magic about any part of the filesystem. As long as the shell can find your executables, and the loader can find your libraries, it will run. But it's not as smart as it sounds.
A great many libraries are used by more than one executable, package, or even family of packages. Where do those libraries go? They don't belong to any particular application. I suppose you could have a different directory for each library package, but what does that get us? Thousands of directories with a handful of library files in each? What's the advantage of that?
Separating files by their intended purpose, the way traditional *nix does, has some advantages. For example, by having executables separate from libraries, the system spends less time searching inapplicable files when you invoke a command name. By having platform-independent files under /usr/share/, one can have share that tree across architectures. Not needed on a traditional personal computer, but in a "cloud computing" design with multiple platforms coming into use on demand, it's quite useful.
I suspect the "one directory per package" mentality is largely driven by the closed-source world, where code sharing is rare, and software tends to be isolated. In the Free/Open Software world, it's very common for many different authors to both provide and make use of others' libraries and resources. Diving things into "products" doesn't make nearly as much sense there.
As a result, any old fool can publish an app in the Android Market with 1/10th the experience and skill required to be in Debian.
Debian (and most other distributions) have rather higher standards of quality. You have to do things like provide documentation, declare your dependencies on shared libraries, etc. This makes the system work better. It does mean "any fool" can't get their software into the distribution. But why would I want software written by a fool? Badly written software causes me pain.
maybe we should instead dump all of an applications files into shared directories, where they can clobber each other
It's the job of the package manager to keep things from clobbering each other, and it generally does a pretty good job. Anything installed on a system can potentially effect that system -- simply using different directories won't make that problem go away. That's why package managers exist in the first place.
Merging /lib and /usr/lib?
I think the /usr vs root distinction is less relevant than it used to be (what with even tiny computers having huge storage), but I do still think there's benefit to keeping a minimal but useful subset that can be used to fix the rest of the system. MS Windows has to use a "recovery environment" for that. I much prefer the idea that the rescue system can just be a smaller portion of the main system. Sure, sometimes it will be totally hosed and you need to boot from some other media, but plenty of times it's just that a more complicated subsystem has gotten broken, and it's nice to be able to fix that in-place.
They address that by saying "There is no way to reliably bring up a modern system with an empty /usr, there are two alternatives to fix it: copy /usr back to the rootfs or use an initramfs which can hide the split-off from the system."
Of course, they conveniently omit the third option: Fix their init system so it doesn't depend on half the software ever written just to bring up a basic system.
Unix wins because it follows KISS. Fedora (and others) have been moving away from that. It's not good.
Given the prevalence of libraries being used by more than one program, trying to organize things into directories-per-program doesn't make a whole lot of sense to me. You'd really need to have a different directories for each package. So now you've got thousands of package folders, each with a handful of files. What does that get us?
I think the idea of keeping track of what files belong to what package is the job of the package manager, not the filesystem layout.
As a historical note, "coder" used to be a separate job role from "programmer". Programmers wrote programs. On paper. Coders had the job of translating the program into machine code and entering it on the card punch. An early assembly-language system was dubbed "auto-coder" for that reason.
(There's some similarity here with how "computer" used to be a job description as well.)
I'm not sure it's even possible to create software that does *the same thing* as a discreet circuit
That would be quite easy. It's the opposite way that's often impossible. Problems that can be easily solved in software are often too complex to solve in hardware.
Software which *includes* (proper superset) the features of a discrete control solution is easy, sure. But software that does *the same thing* as a discrete control (mutually inclusive)? Not so much. Certainly if you're programming anything fancier than a fairly simple microcontroller, you're going to start doing a lot more things that weren't happening before.
Complexity breeds failure. Complex software doing complex things is going to be less reliable than simple solutions doing simple things. If you want a robust system, design many small parts doing simple things, and strive for high cohesion and low coupling. That way, when the system running the catalytic converter tuning fails, the cruise control is completely unaffected.
That does mean you don't get to have a single computer controlling every aspect of the car, though. Higher costs and less sexy.
In fact, discreet circuits are theoretically harder to test than software that does the same thing and certainly harder to debug.
People like you scare me.
I'm not sure it's even possible to create software that does *the same thing* as a discreet circuit. If it is possible, it's never done in practice. Software invariably does more. (Trivial example: Memory management.) And that is where the problem lies.
Discrete controls will be assigned to one task and one task only (because making them do more makes the problem more complex, and thus involves more work). In practice, this makes them easier to test and debug.
Software will be assigned multiple tasks, for reasons unknown, but probably related to misguided thinking similar to the parent poster's. This still makes the problem more complex, but for some reason complexity in software is regarded as "feature rich".
"This is a test. This is only a test. If this had been an actual emergency, you would have been writhing on the ground in unspeakable pain, bleeding from every orifice, while your skin peeled off in long, black, ragged strips. This was only a test." (Unknown)
What I find more interesting is they posted an email address which they claim goes to the person who screwed up. It's obviously an alias created for the occasion, but it still might actually go to that person. If it does, that shows a measure of accountability that is almost unheard of these days.
Of course, it might also just go to the bitbucket.
IIRC, in the "golden age of air travel", airlines were heavily regulated.
The airlines won't treat their customers with malice and disrespect.
HAH! Have you ever flown before? :)
The TSA is easily the worst of two evils, but airlines are notorious for their poor customer service. The big difference, of course, being that you can usually choose a different airline.
Hmmm....
* The remote would have only two buttons.
* You wouldn't be able to remove channels from your channel list -- who needs to delete channels in this day and age?
* There would be a "Beta" logo overlaid on the screen at all times.
* Channels would randomly appear without an explanation of what their programming would be, and then disappear quietly a year or two later.
* And, of course, every channel, show and commercial you ever watched would be tracked forever.
Anyone else?
Somewhere in China there's a factory that makes the internals for ALL cheap printers and depending on incoming orders puts them in a slightly different case and slaps a different sticker on the box.
While there are some shared laser print engines, I've also seen quite a bit of differentiation.
For example, Espon's inkjets don't appear to share much of anything with HP. The carriage is a very different design, the paper feed mechanism is a different layout, the control software has nothing in common, and the drivers are night-and-day different. HP's drivers are hundreds of megabytes and buggier than Maine in June; Epson's are 3-5 MB and are well-behaved.
Or compare HP's laser printers with Lexmark. Lexmark uses a two-piece design for consumables (separate toner and photodrum), while HP uses a single cartridge for both. Again, HP's driver is bloated and unstable; Lexmark's is compact and unobtrusive.
Now, they might well all be assembled in the same factory in Malaysia, but if so, it's out of different parts.
There are toner page counters in the high-end stuff. It's how the consumables monitoring/reporting works, and that's good to have. It's just the printer firmware doesn't refuse to work once the page count exceeds the rated life.
While I can't speak to the parent poster, I can say it varies by engine, body style and transmission type. The turbo models obviously use more fuel. The hatchback and the sedan aren't always comparable (depending on the model year). The manual transmission is better than the conventional automatic, and the CVT is better than either.
In my 2010 Impreza 2.5i hatchback w/ manual trans, I get around 28 MPG real-world, and I drive like a maniac. If I drive for fuel efficiency I can easily make 34 MPG. The CVT can supposedly come close to 40 MPG. 49 seems high to me but he might be in a different market that has different engines. (Maybe there's a diesel somewhere.)
The real news here is that this shows just how poorly conceived this idea was, and a real lack of planning and vision at the top. Not good. Netflix must really be feeling the heat from the studios -- not to mention competition -- to be flailing about like this.