First, I'll admit that I didn't specify OS X. I referred to it indirectly by saying, 'has been for years', but I can see how a person could read that another way. My bad.
That said, though, critters like the WDEF virus weren't exactly a 'plague' in terms of distribution or severity. They were sparse and relatively benign. They existed before the internet became the major conduit for passing information between computers, and could only propagate via physical media. That put some serious limits on their speed of propagation. In fact, it puts them in the category of exploits that only propagate through direct action of a human with physical access to the computer, and there's still some debate on whether to put such exploits in the same category as full-auto viruses like Blaster &co.
When it comes to full-auto viruses, the Mac's reputation for security goes well back past OS9. Remember the 'Hack a Mac' contests back in the late 90s? The only reason anyone managed to win was by taking advantage of a bug in a third-party script running under the webserver. To the best of my knowledge, there was never a successful exploit against the Mac OS in its out-of-the-box configuration. In point of fact, many military sites used pre-OS-X Macs for webservers specifically because they had such a good reputation for being uncracked.
(And just for context, this took place at the same time people could BSOD a Windows machine anywhere on the internet by sending it The Ping of Death)
---- Apple's massive marketing campaign would have you believe that on the day your Mac shows up, it will be impenetrable by viruses.
Pragmatically, Macs are impenetrable by viruses, and have been for years.
If you want to counter that argument in concrete terms, by showing a Mac virus with 1/100th the penetration of Blaster, Nimda, Sobig, et al, feel free. If you can't, you'll have to admit that historically, Macs have not been penetrated to 1/100th the degree that Windows machines have.
If you want to make a hard prediction that Macs will be penetrated to N degree within the next X months, go ahead. If not, you'll have to admit that you can't be confident in making such a prediction.
If you want to present evidence that Macs are about to be compromised through a specific vector, trot it out. If you can't, you'll have to admit you don't have any evidence that would support such a claim.
If all you can really bring against the Mac is a pack of abstractions that boil down to, "nothing is perfect," nobody cares. It's a truism that has no practical meaning.
If you want to say something useful about a Mac's vulnerability, put it in concrete terms. Is having your Mac hijacked by malware more or less likely than getting killed in a car crash? Is it more or less likely than dying by falling down the stairs? Is it more or less likely than being struck by lightning? Is it more or less likely than winning the lottery? Is it more or less likely than having a meteorite come crashing through your roof?
If you think it's more likely than any of those things, show me the numbers to back it up.
Oh fer Pete's sake.. Leave Artie McStrawman alone. Those of us in the Apple camp don't want him.
Once you get past your fascination with Artie, you'll see that many Mac users do not, in fact, think the Mac is utterly and totally bulletproof. OTOH, we're also aware that compromised Windows machines can be found by the hundreds of thousands in the botnets that generated some 90% of the email (spam) traffic last December, while there hasn't been a single large-scale exploit of the Mac since OS X came out.
The sheer difference in exploit numbers suggests that the Mac has some good things going for it in terms of security. Does that make the Mac perfect? Of course not. Does that make the Mac less likely to suffer data loss or force its owner to waste time checking for digital cockroaches every day?
Apple's desire to fix the issues can be summed up in the words, "can we make money doing it?"
It's easy to write a checklist of features that would make up a dream enterprise service package. It's harder to make that package turn a profit in the market. And it's easy for companies to use checklists to justify sticking with the status quo rather than trying something new.
Someone earlier in the thread mentioned 4-hour onsite service, for instance.. for desktop machines, not xServes sitting back in the machine room. Lemme tell ya: I've worked for a couple of large companies and have never seen an IT deal that involves 4-hour onsite service guarantees for any random PC sitting on an everyday worker's desktop. Mission-critical servers, yes. Buy-em-by-the-carload boxes that let users connect to the mission-critical servers? Not a chance. Keeping those running is what the IT department's job. And even then, good luck getting 4-hour turnaround on any issue that doesn't cause significant financial losses from the moment it crops up to the moment the system is fixed and running again. For problems that can be stopped by pulling the network cable out of the wall and shutting off the machine, that's exactly as much ASAP service as you'll get. Anything else will happen later, maybe, if it turns out that we really have to.
These checklists of 'things Apple has to do to compete in the enterprise market' smell to me more like excuses not to spend time exploring alternatives than things people would actually buy if Apple made them available.
Companies don't buy Macs because they don't use Macs now. Simple as that. They already have a large and complex body of hardware and software doing mission-critical things, and it all more or less works the way it is. Adding more machines that are basically the same is known to be reasonably easy. Even if there are teething problems, those tend to get identified early and worked around. Trying something new raises the spectre of potential compatability issues in any of a million undocumented places.
Apple will gain entry to the enterprise market as enterprises move away from proprietary formats and protocols, thus making it easy to fit any standards-compliant machine into the system. And even then, someone will have to lock the beancounters out of the room long enough to explain that a low cost of acquisition does not necessarily equal low TCO.
Of course, a series of negative miracles could happen to Dell (they're in a bad patch right now, but I think they can turn it around) and make Apple look like an island of stability in a PC market that's fighting to rebalance itself.
Well, there must be something.. Why else would Windows types spend so much time grumbling, "stupid one-button mouse?";-)
More generally, Windows puts a lot of configuration operations in RMB contextual menus, then buries the non-RMB equivalents in sub-tabs of ambiguously-named control panels in directories where most users rarely go. Having icons automatically snap to a grid is a RMB operation, for instance. How many clicks does it take to turn that option on or off without ever touching the RMB?
Windows may be fully functional with only a one-button mouse (offhand, I don't know if there are any commands where the non-RMB equivalents flat-out don't exist), but the strictly non-RMB version of Windows is a lot less friendly than OS X.
As I understand it, there are two general schools of thought: One group, made up of older, generally nontechnical senior executives who've spent their entire careers with a lock on music production and distribution, Just Doesn't Get this whole 'internet' thing. They want to believe in DRM, regardless of how often it fails in the market or how many times it proves impossible to implement, because DRM promises them that they can keep doing business the same way they always have.
The second group, made up of younger people with less clout, Does Get It. They know that DRM will never work the way the old guard want it to. The know that DRM pisses off consumers. They know that suing your own customers is lousy business. And they know that the internet has permanently broken their lock on the production and distribution of music. They just don't have a business model they can put forward which will make as much money as the one they're using now, and they certainly don't have anything that looks as good to the old-guard as the wet dream of being able to control music right up to the moment it reaches the customer's ears.
The old guard wants to hang on to its power. That's what old guards do. Not only does it want to keep its existing power, it wants even more power. And that makes the old guard willing to believe anyone who can bring them a good, technical-sounding pitch that boils down to, "you can keep all the control you have today, and get even more."
The situation will change after the old guard has wasted enough hundreds of millions of dollars on newer (but never better) snake-oil schemes that the sheer waste is obvious to everyone. Hell, remember back in 1998 when the labels formed their own industry consortium to establish a DRM standard? That's the one that threatened-to-sue-then-denied-ever-threatening-to- sue Ed Felten for breaking their "we challenge the world to break this" DRM and having the sheer gall to publish an academic report explaining what he and his team had done.
The labels only started talking to Apple after that group fell apart and everyone could see that the whole thing had been a colossal waste of time, effort, and money.
As far as I know, Microsoft doesn't have any contracts with the labels that say it has to close any holes found in PlaysForSure within N weeks, where N is small.
Apple does. Steve says so, right in that same letter.
Think about the screw-potential implicit in that scenario: Apple develops and licenses FairPlay. Apple also sells music through the iTunes store. Apple has 80% of the legal paid download market. All Apple's competitors know that Apple can lose its license to sell music through the iTunes store if a FairPlay hole isn't closed within N weeks.
Exactly how motivated will those competitors be to patch existing holes when they know that dragging their feet can put Apple's contracts with the labels in jeopardy? And assuming they do that, just how sympathetic do you think the record labels will be next time contract negotiations roll around, and Apple still doesn't want variable-rate pricing or to pay a $1-per-iPod "all your customers are thieves" surcharge?
Microsoft produced PlaysForSure as a product it would license to others. They never intended to get into the music distribution business themselves. It was only after the 'selling DRM to third party distributors who have the actual IP licenses with the labels' business model spent years going nowhere that Microsoft decided to get into music sales for itself.
And you'll notice that the DRM Micosoft uses for its own integrated player-and-store (the Zune) isn't being licensed to third parties, either.
OS X: The only GUI with any market penetration that works with N mouse buttons, for N >= 1.
No other major GUI can say that. They don't just support using a multi-button mouse, they require it. They're like the DVD players that don't have enough buttons on the front panel to navigate the menus and play a specific scene from a movie.. they don't have a remote, they depend on the remote.
OS X can scale up to N>1-button mice smoothly and easily. Take away the right mouse-button, and no other GUI is quite as usable as OS X.
Clearly Apple is the one making the 'limited' and 'inferior' product.
Two files.. one compressed, one uncompressed. Both contain roughly equal amounts of information, both take roughly the same time to transfer from storage.
In other words, a 'compression' system with roughly a 1:1 compression ratio. Yeah.. using that would be pretty dumb. You might want to consider using a compression algorithm that actually compresses the data.
Gzip, for instance, offers a compression ratio of about 3:1 for arbitrary text. One read of zipfile equals three reads of uncompressed text.
A 7200 RPM drive has an average seek time of roughly 8ms and an average seek latency of half that (4ms). Call it 12ms per read. Pulling a gzipped file to the CPU in one read saves me 24ms over pulling an uncompressed version of the same file to the CPU in three reads.
In other words, gzipped XML is about 200% more efficient than uncompressed plaintext with any other form of markup. The more compact your markup is, the more obviously you'll feel the hit from the 3:1 compression ratio of gzipping the human-readable text.
If we're only talking uncompressed text with XML versus uncompressed text with some 'compact' form of markup (like, say, binary XML), it probably won't make much difference.
A 2GHz processor can execute roughly 24 million operations in the 12ms necessary to read a block of data from the drive. It's highly unlikely that you'll actually execute 24 million operations on a word processing file.. a grep probably wouldn't cost you 50 operations per character, for instance.. so what's most likely to happen is that you'll finish all the processing for the block of data you've just read in the first 2-5ms of your 12ms read latency, and spend the remaining 10ms sitting there with a stalled CPU.
If dealing with XML means you spend 3-6ms processing the data and only 9ms with the CPU stalled, the outcome is still the same over the long run. Both jobs will complete in roughly the same amount of time.
OTOH, spending CPU cycles uncompressing a zipfile is very efficient, because it would take three reads worth of CPU time (24ms.. 48 million operations) to slow a gzip down to the point where it was only as fast as reading uncompressed files from the drive. And uncompressing a gzip file is much more efficient than that.
Wow..you really need a copy of Transaction Processing by Jim Gray.
IIRC, it takes something like 10,000 operations to open a connection to a database server, another 1000 to parse the SQL, then however many are necessary to process the data itself. And that doesn't count the time losses for network latency for database servers that live on another machine, or process swapping for servers that live on the same machine.
A sorting algorithm written directly into your program will execute less code by an order of magnitude or so, and doesn't induce network/IPC latencies.
If you have a large dataset, you can amortize the startup latency of the database connection into the O(n log n) time spent cranking the data itself, but it takes a lot of data to make 10k-operations-plus-latencies statistically insignificant. For small-to-medium batches of data, even bubblesort is faster than using a database.
Last time I looked at my bookshelf, there were three: Vol 1 - Fundamental Algorithms,Vol 2 - Seminumerical Algorithms, and Vol 3 - Sorting and Saerching. There have also been three fascicles of Vol 4 - Combinatorial Algorithms released on the web, though the book itself hasn't gone to print yet, AFAIK.
In today's world, people have to deal with too many different categories of information to become even competent laymen in all of them.
Do you know how your clothes are made? Do you know how your local power grid is laid out? Do you know how groceries are stocked in the store, or how to manage the logistics of getting food from all over the world into a single building? Do you know how roads are paved, water is delivered, sewage is handled, or waste is disposed of? Do you know the legal legal issues relevant to any of those fields?
Take fifteen minutes and try to list all the things you'd need to learn and build in order to make a ballpoint pen from scratch.. and I mean really from scratch. You don't get to order plastics and machinery from suppliers. Start with a patch of earth that magically contains all the funamental materials you need, and your bare hands. If you have to list fifteen different things before you even get to 'make a decent shovel', you're on the right track.
Our society works because we all cooperate, and generally trust each other. We trust the experts in textiles, power, etc. to do their jobs well enough that we don't have to become experts just to meet our own basic needs.
I don't think people should reject all forms of external storage and try to live by memorizing everything. Putting information into the world (to use a term Don Norman explored in The Psychology of Everyday Things [1]) is a Way Good Thing.
Cellphones and laptops are too fragile to make good storage media, though. It's too easy to put them into a state where you can't get any of the information back out of them. Laminated paper, like the cards I hand out, is far more durable, portable, and reliable. Unfortunately, it's also hard to come by, compared to just saving a number in a cell phone.
[1] - A great book on design theory and usability. He uses the phrase, "it probably won an award" as a curse, and tells stories like the two guys trying to figure out a new coffee maker: one said, "You'd need an engineering degree from MIT to work this thing," and the other says, "I *have* an engineering degree from MIT."
When you grow up and learn how computers really work, you'll understand that 'simplicity' usually means 'lousy performance' in high-load situations. It's 'simple' to let your cores sit idle 90% of the time while they wait for data to crawl along the PCI bus, but your users won't thank you for the additional wait.
Here's an analogy that might fit into your tiny little mind: pushing uncompressed text files across the PCI bus is like pushing uncompressed images across a network. You can send a 640x480 image across a network as 900K of uncompressed bitmap data, or you can send it as a 100K JPEG. The bitmap is 'simpler' than the JPEG, since it takes less processing power to decide what to paint on the screen. But most computers can decompress the JPEG faster than most networks can transfer 900K of data.
Of course, I don't know why I'm even writing this part, since you clearly haven't read more than the first line of anything I've said.. otherwise, you'd have twigged onto the BINARY XML theme by now.
To be fair, Pascal was originally designed as a teaching tool and to match the real-world value of say, C, you have to bolt on some extensions. That works, but it's less than perfect.
The Modula family of languages, OTOH, are way cool.
I work as a supervisor, and don't want to tell you how many people I've seen come in late for work, saying, 'I would have called in to let you know, but my phone was dead and I couldn't remember the number." There's no reason for that to be a lie.. there's no penalty for calling in, but two no-call/no-shows will get you fired. It's common enough that I've taken to handing out laminated cards with all our division's phone numbers.
I also see about one person every two or three months who's lost their cell phone, or had one die in a way that makes it impossible for them to recover their numbers. You can tell them by the thousand-yard stare, as they cope with the idea of trying to get all those numbers back.
Yeah, there are significant benefits to storing information in the world rather than in your head. But information stored in your head has the benefit of being available to you any time, anywhere.
First of all, grep runs sequentially. Any system with decent SMP will automatically create a pipeline where one set of cores unzips files and another set of cores scans the results. Given enough cores, the system will self-balance to the most efficient mix of unzippers and scanners.
Second, if you're scanning ten million files, your choke point will be disk I/O, not CPU load, since the CPU is a few million times faster than the disk bus. It's called the Von Neumann Bottleneck. Even if you have a few terabytes of RAM and no disk at all, your I/O latency will probably still outweigh the CPU cost of unzipping the files. In fact, it's possible that using zipped files would be faster, since you're dragging fewer bytes per file across the bus, and letting the cores exract data rather than sitting idle while they wait for the next read-cycle to complete.
Third, if you're going to do that kind of thing on a regular basis, you'd be advised to write a custom grep that knows how to read a zipfile's dictionary so it doesn't have to unzip the files at all. Even so, you're still gonna take it in the 'nads from device I/O.
A) You did make it past the second paragraph, right?
Let's try it once more for the hard-of-thinking, though: If you find yourself in a situation where you can't justify the CPU load of unzipping the files or the data load of using unzipped files with human-readable tags, then you have the option of translating ODF to binary XML.
Because.. y'know.. if your users are going to be doing things like that on a regular basis, it's worth running a single, slow, batch translation on all your files. Heck, you can even write a plugin for the FOSS word processors that will read and write binary XML directly, and you won't have to keep converting documents.
B) Exactly how many users do you expect to see having that problem, worldwide, in any given day?
For the remaining 99.999999999% of us (heck, I'll give you a couple extra orders of magnitude and call it 99.9999999%), ODF looks like a decent format.
---- Software installation needs to be simple as: click on package, enter password to authorize installation, use newly installed software.
No, software installation needs to be as simple as: copy the file/directory from the install media to the hard drive, use newly installed software.
Installer packages and authentication make it too damned easy for developers to feel casual about installing things in places the 'inexperienced user' (which IMO includes about 60% of developers) shouldn't go.
I should not need admin-level authentication to install an image viewer that will only be run at regular-user privileges, simply because the developer thinks he's doing me a favor by 'updating' all my libraries. Damn thing should default to running inside a chroot jail, as far as I'm concerned.
I don't buy the idea that dynamic libraries make it fast and easy to do a system-wide upgrade if a critical bug is found. They make it equally easy to do a system-wide downgrade the next time I install something from an old package, to hose the system royally if two installers want incompatible versions of some dependency, and to create segmented, "the program itself is small, but look at that dependency chain" bloatware.
Let's get the distros to agree on a set of dynamic libraries they're all willing to support, and leave the business of keeping those libraries updated to the distros. Developers can then rely on those libraries being available on any distro or flavor of Linux/BSD/whatever. If a developer wants something outside that list, let him link it statically.
Bottom line, though, I want developers to ship software that works, not sitting around deciding what's "good" for me.
---- Why the fsck do some users insist on installing software outside their own distributions?
Uh.. because they want to?
Because they think the software might do something they want?
Because they think an OS should be able to.. oh, I dunno.. run software?
Because they want to choose software for themselves, not leave the decision to some central committee that will tell them what options they're allowed to have? [1]
Because you've got the question precisely backwards, and the one that really matters is the user's question of, "does this OS/distro let me do what I want?"
Let's face it, if the answer to that question is, "no," you can pretty well forget about the world beating a path to your door. But that's okay, because apparently you don't want them there, anyway.
Stupid damn users.. thinking they should be allowed to choose software..
[1] - Seriously dude.. drop the "why can't they just do what we tell them to" meme.. NOW. Friends don't let friends evolve into spokesmen for the RIAA/MPAA.
IIRC, this procedure creates bubbles much bigger, and thus much hotter, than any previous version.
There's no theoretical barrier that makes sonofusion impossible. It's just a very difficult engineering problem. The more we learn about making very small bubbles hotter, the closer we'll be to getting something that does pass the break-even point.
And just for the record, very-large-and-very-hot fusion hasn't passed the break-even point either, AFAIK.
Yeah.. because everyone knows today's multi-core processors really have to strain themselves to do a huffman-encoded dictionary translation.
Wake up and smell the 21st century. You burn more CPU cycles per byte encoding and decoding SSH traffic or passing data over a WEP-protected wireless network than you do packing and unpacking a zipfile. And let's not even talk about the processor intensity of JPEGs, PNGs (gotta love that alpha-channel compositing), or -- God forbid -- MP3s.
Besides, gzipping is only one way to compress ODF. The people who deal in high-volume data processing have done plenty of work on binary XML. The fact that ODF is an open standard makes it more or less trivial to write a program that translates tags to 16-bit tokens, which reduces markup overhead to a whopping two Unicode characters per tag, assuming you can devise a set of working conditions where the data overhead of human-readable tags and the processing overhead of gzip translation are both unacceptable.
Face it: storage costs less than a dollar per gigabyte these days, gigabit-per-second data transfer exists at consumer prices, and most people have more processing power on their desktop than existed in the first four generations of supercomputers. The value of bit-squinting has decreased exponentially since the 1950s, and these days it's vanishingly small except under very-high-load conditions.
And ODF's openness makes it friendly to people who find themselves working in very-high-load conditions.
The irony lies in the number of Slashdotters who'll climb up on their high horse to rant about the fundamental illegality of anything that keeps them from doing whatever the hell they want with music, but whose little heads would explode if Microsoft tried to apply exactly the same reasoning to Linux.
Slashdot Mirror
First, I'll admit that I didn't specify OS X. I referred to it indirectly by saying, 'has been for years', but I can see how a person could read that another way. My bad.
That said, though, critters like the WDEF virus weren't exactly a 'plague' in terms of distribution or severity. They were sparse and relatively benign. They existed before the internet became the major conduit for passing information between computers, and could only propagate via physical media. That put some serious limits on their speed of propagation. In fact, it puts them in the category of exploits that only propagate through direct action of a human with physical access to the computer, and there's still some debate on whether to put such exploits in the same category as full-auto viruses like Blaster &co.
When it comes to full-auto viruses, the Mac's reputation for security goes well back past OS9. Remember the 'Hack a Mac' contests back in the late 90s? The only reason anyone managed to win was by taking advantage of a bug in a third-party script running under the webserver. To the best of my knowledge, there was never a successful exploit against the Mac OS in its out-of-the-box configuration. In point of fact, many military sites used pre-OS-X Macs for webservers specifically because they had such a good reputation for being uncracked.
(And just for context, this took place at the same time people could BSOD a Windows machine anywhere on the internet by sending it The Ping of Death)
---- Apple's massive marketing campaign would have you believe that on the day your Mac shows up, it will be impenetrable by viruses.
Pragmatically, Macs are impenetrable by viruses, and have been for years.
If you want to counter that argument in concrete terms, by showing a Mac virus with 1/100th the penetration of Blaster, Nimda, Sobig, et al, feel free. If you can't, you'll have to admit that historically, Macs have not been penetrated to 1/100th the degree that Windows machines have.
If you want to make a hard prediction that Macs will be penetrated to N degree within the next X months, go ahead. If not, you'll have to admit that you can't be confident in making such a prediction.
If you want to present evidence that Macs are about to be compromised through a specific vector, trot it out. If you can't, you'll have to admit you don't have any evidence that would support such a claim.
If all you can really bring against the Mac is a pack of abstractions that boil down to, "nothing is perfect," nobody cares. It's a truism that has no practical meaning.
If you want to say something useful about a Mac's vulnerability, put it in concrete terms. Is having your Mac hijacked by malware more or less likely than getting killed in a car crash? Is it more or less likely than dying by falling down the stairs? Is it more or less likely than being struck by lightning? Is it more or less likely than winning the lottery? Is it more or less likely than having a meteorite come crashing through your roof?
If you think it's more likely than any of those things, show me the numbers to back it up.
Oh fer Pete's sake.. Leave Artie McStrawman alone. Those of us in the Apple camp don't want him.
Once you get past your fascination with Artie, you'll see that many Mac users do not, in fact, think the Mac is utterly and totally bulletproof. OTOH, we're also aware that compromised Windows machines can be found by the hundreds of thousands in the botnets that generated some 90% of the email (spam) traffic last December, while there hasn't been a single large-scale exploit of the Mac since OS X came out.
The sheer difference in exploit numbers suggests that the Mac has some good things going for it in terms of security. Does that make the Mac perfect? Of course not. Does that make the Mac less likely to suffer data loss or force its owner to waste time checking for digital cockroaches every day?
Yes.
Apple's desire to fix the issues can be summed up in the words, "can we make money doing it?"
It's easy to write a checklist of features that would make up a dream enterprise service package. It's harder to make that package turn a profit in the market. And it's easy for companies to use checklists to justify sticking with the status quo rather than trying something new.
Someone earlier in the thread mentioned 4-hour onsite service, for instance.. for desktop machines, not xServes sitting back in the machine room. Lemme tell ya: I've worked for a couple of large companies and have never seen an IT deal that involves 4-hour onsite service guarantees for any random PC sitting on an everyday worker's desktop. Mission-critical servers, yes. Buy-em-by-the-carload boxes that let users connect to the mission-critical servers? Not a chance. Keeping those running is what the IT department's job. And even then, good luck getting 4-hour turnaround on any issue that doesn't cause significant financial losses from the moment it crops up to the moment the system is fixed and running again. For problems that can be stopped by pulling the network cable out of the wall and shutting off the machine, that's exactly as much ASAP service as you'll get. Anything else will happen later, maybe, if it turns out that we really have to.
These checklists of 'things Apple has to do to compete in the enterprise market' smell to me more like excuses not to spend time exploring alternatives than things people would actually buy if Apple made them available.
Companies don't buy Macs because they don't use Macs now. Simple as that. They already have a large and complex body of hardware and software doing mission-critical things, and it all more or less works the way it is. Adding more machines that are basically the same is known to be reasonably easy. Even if there are teething problems, those tend to get identified early and worked around. Trying something new raises the spectre of potential compatability issues in any of a million undocumented places.
Apple will gain entry to the enterprise market as enterprises move away from proprietary formats and protocols, thus making it easy to fit any standards-compliant machine into the system. And even then, someone will have to lock the beancounters out of the room long enough to explain that a low cost of acquisition does not necessarily equal low TCO.
Of course, a series of negative miracles could happen to Dell (they're in a bad patch right now, but I think they can turn it around) and make Apple look like an island of stability in a PC market that's fighting to rebalance itself.
---- Oh? What in Windows requires the RMB?
;-)
Well, there must be something.. Why else would Windows types spend so much time grumbling, "stupid one-button mouse?"
More generally, Windows puts a lot of configuration operations in RMB contextual menus, then buries the non-RMB equivalents in sub-tabs of ambiguously-named control panels in directories where most users rarely go. Having icons automatically snap to a grid is a RMB operation, for instance. How many clicks does it take to turn that option on or off without ever touching the RMB?
Windows may be fully functional with only a one-button mouse (offhand, I don't know if there are any commands where the non-RMB equivalents flat-out don't exist), but the strictly non-RMB version of Windows is a lot less friendly than OS X.
As I understand it, there are two general schools of thought: One group, made up of older, generally nontechnical senior executives who've spent their entire careers with a lock on music production and distribution, Just Doesn't Get this whole 'internet' thing. They want to believe in DRM, regardless of how often it fails in the market or how many times it proves impossible to implement, because DRM promises them that they can keep doing business the same way they always have.
- sue Ed Felten for breaking their "we challenge the world to break this" DRM and having the sheer gall to publish an academic report explaining what he and his team had done.
The second group, made up of younger people with less clout, Does Get It. They know that DRM will never work the way the old guard want it to. The know that DRM pisses off consumers. They know that suing your own customers is lousy business. And they know that the internet has permanently broken their lock on the production and distribution of music. They just don't have a business model they can put forward which will make as much money as the one they're using now, and they certainly don't have anything that looks as good to the old-guard as the wet dream of being able to control music right up to the moment it reaches the customer's ears.
The old guard wants to hang on to its power. That's what old guards do. Not only does it want to keep its existing power, it wants even more power. And that makes the old guard willing to believe anyone who can bring them a good, technical-sounding pitch that boils down to, "you can keep all the control you have today, and get even more."
The situation will change after the old guard has wasted enough hundreds of millions of dollars on newer (but never better) snake-oil schemes that the sheer waste is obvious to everyone. Hell, remember back in 1998 when the labels formed their own industry consortium to establish a DRM standard? That's the one that threatened-to-sue-then-denied-ever-threatening-to
The labels only started talking to Apple after that group fell apart and everyone could see that the whole thing had been a colossal waste of time, effort, and money.
Time constraints.
As far as I know, Microsoft doesn't have any contracts with the labels that say it has to close any holes found in PlaysForSure within N weeks, where N is small.
Apple does. Steve says so, right in that same letter.
Think about the screw-potential implicit in that scenario: Apple develops and licenses FairPlay. Apple also sells music through the iTunes store. Apple has 80% of the legal paid download market. All Apple's competitors know that Apple can lose its license to sell music through the iTunes store if a FairPlay hole isn't closed within N weeks.
Exactly how motivated will those competitors be to patch existing holes when they know that dragging their feet can put Apple's contracts with the labels in jeopardy? And assuming they do that, just how sympathetic do you think the record labels will be next time contract negotiations roll around, and Apple still doesn't want variable-rate pricing or to pay a $1-per-iPod "all your customers are thieves" surcharge?
Microsoft produced PlaysForSure as a product it would license to others. They never intended to get into the music distribution business themselves. It was only after the 'selling DRM to third party distributors who have the actual IP licenses with the labels' business model spent years going nowhere that Microsoft decided to get into music sales for itself.
And you'll notice that the DRM Micosoft uses for its own integrated player-and-store (the Zune) isn't being licensed to third parties, either.
OS X: The only GUI with any market penetration that works with N mouse buttons, for N >= 1.
No other major GUI can say that. They don't just support using a multi-button mouse, they require it. They're like the DVD players that don't have enough buttons on the front panel to navigate the menus and play a specific scene from a movie.. they don't have a remote, they depend on the remote.
OS X can scale up to N>1-button mice smoothly and easily. Take away the right mouse-button, and no other GUI is quite as usable as OS X.
Clearly Apple is the one making the 'limited' and 'inferior' product.
Two files.. one compressed, one uncompressed. Both contain roughly equal amounts of information, both take roughly the same time to transfer from storage.
In other words, a 'compression' system with roughly a 1:1 compression ratio. Yeah.. using that would be pretty dumb. You might want to consider using a compression algorithm that actually compresses the data.
Gzip, for instance, offers a compression ratio of about 3:1 for arbitrary text. One read of zipfile equals three reads of uncompressed text.
A 7200 RPM drive has an average seek time of roughly 8ms and an average seek latency of half that (4ms). Call it 12ms per read. Pulling a gzipped file to the CPU in one read saves me 24ms over pulling an uncompressed version of the same file to the CPU in three reads.
In other words, gzipped XML is about 200% more efficient than uncompressed plaintext with any other form of markup. The more compact your markup is, the more obviously you'll feel the hit from the 3:1 compression ratio of gzipping the human-readable text.
If we're only talking uncompressed text with XML versus uncompressed text with some 'compact' form of markup (like, say, binary XML), it probably won't make much difference.
A 2GHz processor can execute roughly 24 million operations in the 12ms necessary to read a block of data from the drive. It's highly unlikely that you'll actually execute 24 million operations on a word processing file.. a grep probably wouldn't cost you 50 operations per character, for instance.. so what's most likely to happen is that you'll finish all the processing for the block of data you've just read in the first 2-5ms of your 12ms read latency, and spend the remaining 10ms sitting there with a stalled CPU.
If dealing with XML means you spend 3-6ms processing the data and only 9ms with the CPU stalled, the outcome is still the same over the long run. Both jobs will complete in roughly the same amount of time.
OTOH, spending CPU cycles uncompressing a zipfile is very efficient, because it would take three reads worth of CPU time (24ms.. 48 million operations) to slow a gzip down to the point where it was only as fast as reading uncompressed files from the drive. And uncompressing a gzip file is much more efficient than that.
Wow..you really need a copy of Transaction Processing by Jim Gray.
IIRC, it takes something like 10,000 operations to open a connection to a database server, another 1000 to parse the SQL, then however many are necessary to process the data itself. And that doesn't count the time losses for network latency for database servers that live on another machine, or process swapping for servers that live on the same machine.
A sorting algorithm written directly into your program will execute less code by an order of magnitude or so, and doesn't induce network/IPC latencies.
If you have a large dataset, you can amortize the startup latency of the database connection into the O(n log n) time spent cranking the data itself, but it takes a lot of data to make 10k-operations-plus-latencies statistically insignificant. For small-to-medium batches of data, even bubblesort is faster than using a database.
Book?
Last time I looked at my bookshelf, there were three: Vol 1 - Fundamental Algorithms, Vol 2 - Seminumerical Algorithms, and Vol 3 - Sorting and Saerching. There have also been three fascicles of Vol 4 - Combinatorial Algorithms released on the web, though the book itself hasn't gone to print yet, AFAIK.
Don't forget collapsible steering columns..
Ah for the good old days of driving down the road with a six-foot steel spear pointed directly at your chest.
It's not even laziness.. it's economics.
In today's world, people have to deal with too many different categories of information to become even competent laymen in all of them.
Do you know how your clothes are made? Do you know how your local power grid is laid out? Do you know how groceries are stocked in the store, or how to manage the logistics of getting food from all over the world into a single building? Do you know how roads are paved, water is delivered, sewage is handled, or waste is disposed of? Do you know the legal legal issues relevant to any of those fields?
Take fifteen minutes and try to list all the things you'd need to learn and build in order to make a ballpoint pen from scratch.. and I mean really from scratch. You don't get to order plastics and machinery from suppliers. Start with a patch of earth that magically contains all the funamental materials you need, and your bare hands. If you have to list fifteen different things before you even get to 'make a decent shovel', you're on the right track.
Our society works because we all cooperate, and generally trust each other. We trust the experts in textiles, power, etc. to do their jobs well enough that we don't have to become experts just to meet our own basic needs.
I don't think people should reject all forms of external storage and try to live by memorizing everything. Putting information into the world (to use a term Don Norman explored in The Psychology of Everyday Things [1]) is a Way Good Thing.
Cellphones and laptops are too fragile to make good storage media, though. It's too easy to put them into a state where you can't get any of the information back out of them. Laminated paper, like the cards I hand out, is far more durable, portable, and reliable. Unfortunately, it's also hard to come by, compared to just saving a number in a cell phone.
[1] - A great book on design theory and usability. He uses the phrase, "it probably won an award" as a curse, and tells stories like the two guys trying to figure out a new coffee maker: one said, "You'd need an engineering degree from MIT to work this thing," and the other says, "I *have* an engineering degree from MIT."
Simpler? No.
Faster? Possibly.
When you grow up and learn how computers really work, you'll understand that 'simplicity' usually means 'lousy performance' in high-load situations. It's 'simple' to let your cores sit idle 90% of the time while they wait for data to crawl along the PCI bus, but your users won't thank you for the additional wait.
Here's an analogy that might fit into your tiny little mind: pushing uncompressed text files across the PCI bus is like pushing uncompressed images across a network. You can send a 640x480 image across a network as 900K of uncompressed bitmap data, or you can send it as a 100K JPEG. The bitmap is 'simpler' than the JPEG, since it takes less processing power to decide what to paint on the screen. But most computers can decompress the JPEG faster than most networks can transfer 900K of data.
Of course, I don't know why I'm even writing this part, since you clearly haven't read more than the first line of anything I've said.. otherwise, you'd have twigged onto the BINARY XML theme by now.
To be fair, Pascal was originally designed as a teaching tool and to match the real-world value of say, C, you have to bolt on some extensions. That works, but it's less than perfect.
The Modula family of languages, OTOH, are way cool.
Fallback capacity?
I work as a supervisor, and don't want to tell you how many people I've seen come in late for work, saying, 'I would have called in to let you know, but my phone was dead and I couldn't remember the number." There's no reason for that to be a lie.. there's no penalty for calling in, but two no-call/no-shows will get you fired. It's common enough that I've taken to handing out laminated cards with all our division's phone numbers.
I also see about one person every two or three months who's lost their cell phone, or had one die in a way that makes it impossible for them to recover their numbers. You can tell them by the thousand-yard stare, as they cope with the idea of trying to get all those numbers back.
Yeah, there are significant benefits to storing information in the world rather than in your head. But information stored in your head has the benefit of being available to you any time, anywhere.
Nope, sorry.
First of all, grep runs sequentially. Any system with decent SMP will automatically create a pipeline where one set of cores unzips files and another set of cores scans the results. Given enough cores, the system will self-balance to the most efficient mix of unzippers and scanners.
Second, if you're scanning ten million files, your choke point will be disk I/O, not CPU load, since the CPU is a few million times faster than the disk bus. It's called the Von Neumann Bottleneck. Even if you have a few terabytes of RAM and no disk at all, your I/O latency will probably still outweigh the CPU cost of unzipping the files. In fact, it's possible that using zipped files would be faster, since you're dragging fewer bytes per file across the bus, and letting the cores exract data rather than sitting idle while they wait for the next read-cycle to complete.
Third, if you're going to do that kind of thing on a regular basis, you'd be advised to write a custom grep that knows how to read a zipfile's dictionary so it doesn't have to unzip the files at all. Even so, you're still gonna take it in the 'nads from device I/O.
A) You did make it past the second paragraph, right?
Let's try it once more for the hard-of-thinking, though: If you find yourself in a situation where you can't justify the CPU load of unzipping the files or the data load of using unzipped files with human-readable tags, then you have the option of translating ODF to binary XML.
Because.. y'know.. if your users are going to be doing things like that on a regular basis, it's worth running a single, slow, batch translation on all your files. Heck, you can even write a plugin for the FOSS word processors that will read and write binary XML directly, and you won't have to keep converting documents.
B) Exactly how many users do you expect to see having that problem, worldwide, in any given day?
For the remaining 99.999999999% of us (heck, I'll give you a couple extra orders of magnitude and call it 99.9999999%), ODF looks like a decent format.
---- Software installation needs to be simple as: click on package, enter password to authorize installation, use newly installed software.
No, software installation needs to be as simple as: copy the file/directory from the install media to the hard drive, use newly installed software.
Installer packages and authentication make it too damned easy for developers to feel casual about installing things in places the 'inexperienced user' (which IMO includes about 60% of developers) shouldn't go.
I should not need admin-level authentication to install an image viewer that will only be run at regular-user privileges, simply because the developer thinks he's doing me a favor by 'updating' all my libraries. Damn thing should default to running inside a chroot jail, as far as I'm concerned.
I don't buy the idea that dynamic libraries make it fast and easy to do a system-wide upgrade if a critical bug is found. They make it equally easy to do a system-wide downgrade the next time I install something from an old package, to hose the system royally if two installers want incompatible versions of some dependency, and to create segmented, "the program itself is small, but look at that dependency chain" bloatware.
Let's get the distros to agree on a set of dynamic libraries they're all willing to support, and leave the business of keeping those libraries updated to the distros. Developers can then rely on those libraries being available on any distro or flavor of Linux/BSD/whatever. If a developer wants something outside that list, let him link it statically.
Bottom line, though, I want developers to ship software that works, not sitting around deciding what's "good" for me.
---- Why the fsck do some users insist on installing software outside their own distributions?
Uh.. because they want to?
Because they think the software might do something they want?
Because they think an OS should be able to.. oh, I dunno.. run software?
Because they want to choose software for themselves, not leave the decision to some central committee that will tell them what options they're allowed to have? [1]
Because you've got the question precisely backwards, and the one that really matters is the user's question of, "does this OS/distro let me do what I want?"
Let's face it, if the answer to that question is, "no," you can pretty well forget about the world beating a path to your door. But that's okay, because apparently you don't want them there, anyway.
Stupid damn users.. thinking they should be allowed to choose software..
[1] - Seriously dude.. drop the "why can't they just do what we tell them to" meme.. NOW. Friends don't let friends evolve into spokesmen for the RIAA/MPAA.
IIRC, this procedure creates bubbles much bigger, and thus much hotter, than any previous version.
There's no theoretical barrier that makes sonofusion impossible. It's just a very difficult engineering problem. The more we learn about making very small bubbles hotter, the closer we'll be to getting something that does pass the break-even point.
And just for the record, very-large-and-very-hot fusion hasn't passed the break-even point either, AFAIK.
Yeah.. because everyone knows today's multi-core processors really have to strain themselves to do a huffman-encoded dictionary translation.
Wake up and smell the 21st century. You burn more CPU cycles per byte encoding and decoding SSH traffic or passing data over a WEP-protected wireless network than you do packing and unpacking a zipfile. And let's not even talk about the processor intensity of JPEGs, PNGs (gotta love that alpha-channel compositing), or -- God forbid -- MP3s.
Besides, gzipping is only one way to compress ODF. The people who deal in high-volume data processing have done plenty of work on binary XML. The fact that ODF is an open standard makes it more or less trivial to write a program that translates tags to 16-bit tokens, which reduces markup overhead to a whopping two Unicode characters per tag, assuming you can devise a set of working conditions where the data overhead of human-readable tags and the processing overhead of gzip translation are both unacceptable.
Face it: storage costs less than a dollar per gigabyte these days, gigabit-per-second data transfer exists at consumer prices, and most people have more processing power on their desktop than existed in the first four generations of supercomputers. The value of bit-squinting has decreased exponentially since the 1950s, and these days it's vanishingly small except under very-high-load conditions.
And ODF's openness makes it friendly to people who find themselves working in very-high-load conditions.
-- Please enter your password to confirm your password confirmation.
The irony lies in the number of Slashdotters who'll climb up on their high horse to rant about the fundamental illegality of anything that keeps them from doing whatever the hell they want with music, but whose little heads would explode if Microsoft tried to apply exactly the same reasoning to Linux.