Still, the folks writing worms (so far) don't exhibit signs of being particularly knowledgeable about Windows. They're basically script kiddies who dare to break out Notepad and fiddle around a bit. I don't know of any source of statistics for failed worm writing attempts, so who knows what the ratio is of wannabe worm authors vs the ones who manage to make one that works.
My point is that even though a given security measure can be defeated by a determined & informed attacker, it may still be worth the effort if it turns away the script kiddies and worms. Most of us don't have anything that's worth a determined & informed attacker's time, whereas a worm doesn't care, and worm authors don't need to account for every possible situation; they attack the default configuration and ignore all the alternate possibilities.
If you mean "the JVM shouldn't interpret the same code each time it runs", it doesn't, or at least not exactly. It JIT-compiles the [frequently called parts of the] code once each time it runs, and then uses the native code from then on. If you kill and restart the JVM, though, it has to re-JIT-compile the code. I suppose a slightly faster mechanism would be to cache the compiled native code to disk, like (IIRC) NT on Alpha did for x86 DLLs, or as.NET's CLR does. But I have yet to see an application that was stymied by JIT compilation overhead - more commonly the problems are overall JVM startup time, JVM memory overhead, or algorithmic mistakes that lead to extreme garbage collection overhead or memory "leaks" (forgotten references that the GC assumes are important).
If you mean "it's stupid to load the code from the network every time", the Java Plug-in has done this for over three years: http://java.sun.com/j2se/1.3/docs/guide/mi sc/apple tcaching.html
Did you miss the part where he said 90" diagonal? You might as well say that he's foolish for spending any more than $99 because you have a mini TV that cost that much.
I'm not trying to make this a Size Matters thing any more than it needs to be. But compare like to like - a 60" rear projection TV runs more like $4500, and is a bastard to get up and down stairs. A few years ago when I bought my LCD projector, Fry's (a local chain in Silicon Valley) was selling a 70" projection-screen TV for $8000.
BTW folks, bear in mind that if you have a home theater and NetFlix, you'll save a TON on things like movie tickets, candy/popcorn, gas, etc. My wife and I have been to the movies three times this year. How much do you spend on going out to the movies every year? (It doesn't have to be a super deluxe home theater, either, no matter what the freaks who spend $30,000 on home theater setups would have you believe.)
That's not a sufficient argument to counter the audiophiles. At the heart of the audiophile point of view is the idea that their ears are superior (innately, or through training) and that they need special ultra-high-end equipment in order to get the maximum enjoyment out of music - enjoyment which vastly exceeds that of the typical listener with plan old hearing on consumer grade equipment.
I think I'll start trolling with complaints about how I can see well into the infrared and ultraviolet spectrum, and that I will settle for nothing less than original film copies of movies because analog film accidentally captures infrared and ultraviolet images as well (even though no one else can see it). HDTV just ruins movies that are better appreciated in film form! Also, glass lenses have a very negative impact on the quality of light, so I only use diamond lenses in my projectors. And to avoid jitter in the frames, the sprockets in my projector are made of titanium so there's no chance that they will wear down over time and fail to grasp the film perfectly.
It's not the computers, it's the users that bog down the non-CS IT departments. You're overlooking the size and skill level of the user base.
CS students (who have gotten past the Freshman level weed-out courses) are likely to me MUCH more tech savvy than, say, a music or statistics major (who mainly want to just run one or two applications and then read email and surf).
Compare that small group of highly technical users, who probably have owned computers for years and years and are embarassed to have to ask for help with printing, etc. (RTFM!), with the hordes of "mundanes" who just have to write a freakin' paper and don't know what "PC Load Letter" means on the printer or why opening attachments is dangerous.
>CS and EE departments make punishing use of their computing resources.
By which you mean, power users run programs that use a lot of CPU resources. Ooo, scary! Non-CS students physically break computers because they don't know better or don't care:
I need more RAM, I think I'll steal it out of a lab computer.
Hey what's this attachment, hey it doesn't seem to be doing anything, hmm now this computer's slow, oh well who cares, I'll use the next one.
Oops, I spilled my coke in the keyboard. I better not tell anybody or I'll have to pay for a new keyboard, and I bet that's expensive.
How nice that they built a cup holder into the front of this computer. Oops, I spilled my coffee into the cup holder opening.
I'm late for class, this printer is slow, maybe if I yank on the paper as it comes out, it'll print faster. Oops, paper jam, I'm outta here.
I love Napster! I think I'll download a bunch more file sharing apps and run them all the time since all my bandwidth is free.
This 22MB MPEG is soooo funny. I think I'll email it to everybody I have an email address for.
>I've worked quite extensively on an ERP application called PeopleSoft. It locates all of it's business logic in the middle tier. The SQL it produces is very database agnostic and will run with minor modification on most database platforms.
The folks I know who have implemented PeopleSoft at Fortune 500 companies complain bitterly about how it's terribly slow even on monster hardware, specifically because it is written to be so database-agnostic. This is not anything to brag about, and is certainly not an indicator that this is a good way to design something. Maybe it made sense for PeopleSoft to be portable at the expense of writing redundant code in the app that's already in major RDBMS products, AND making the app slower by running code in the app tier when it would run faster in the DB tier, but that doesn't mean that this is a good idea in general. Heck, it might even be a plain mistake on PeopleSoft's part that they have just had to live with.
BTW, I'm assuming a connection between two parts of your message here, but... a 10 CPU database server just to achieve hundreds of concurrent users, for an app that deliberately avoids running any code in the database tier? Ouch!
You may have already thought of this, but it probably would be helpful to factor out your persistence layer even though you're not expecting to need another back-end soon. It's cool to be able to make a persistence test harness (test your stored procs instead of your whole app, reducing the LOC you have to look through for each bug) even if you don't need another back-end.
OTOH, in a project that's actually funded, sometimes it's better to just hack something, QA it until it works, and ship it, and fix the internal ickiness (that slows developers down) later.
> Personally though I don't understand why application developers use a database for anything other than storage.
Clearly. But what does storage entail? Transactions? Backup? Concurrent access that works properly in all situations? Availability? Scalability?
> If all you are doing is simple inserts, selects, updates and deletes it should be very easy, if not trivial to make the application database independent.
Great! OK, so what if you AREN'T doing simple inserts, selects, updates, and deletes? If all you do is read and write data from the disk, why even use a database? Just use flat files! Woo hoo!
>Stored procs, triggers, etc, are evil
Exactly. It's much better to put all the persistence logic in the business layer, and make the database stupid so that it can't be clustered. That works way better. I always say, time-tested code can't hold a candle to my team of underpaid sweaty CS dropouts rolling something on their own! Or better yet, they can just overlook all the tricky situations they don't understand, and fix it later when it's in production and loses real data!
>as they spread your application logic all over the place
Because as we all know, single-tier architectures are the wave of the future. It's always better to write all of your code in The One True Programming Language that the alpha coder on the project happens to like, and run it all in one process in one tier.
> and there are no standards for how they are implemented by different vendors. It's hard enough to find a relatively standard subset of SQL semantics.
I'm not sure that there are *no* standards, but practically, it makes more sense to just encapsulate the persistence code for specific database back-ends, and write product-specific code for each back end. If you actually separate persistence logic out from business logic, this isn't very much work, and you can also attach a test harness to the back-ends and make sure they all work properly (reducing the likelihood of having lots of unique bugs in each back end).
Personally I tend to lean on triggers and referential integrity constraints (redundant rule enforcement is GOOD) more than stored procedures, but there are some other things in Oracle (or MS SQL 2K, or DB/2) that aren't in, say, MySQL, and these things are not just silly superfluous features that should be ignored in favor of hand-written replacements in PHP or whatever.
1) Author makes content 2) Author makes content on crappy old 486 because they're essentially free now 3) Artists offers content for syndication 4) Lots of web sites buy author's syndicated content 5) Author gets popular, driving more traffic to sites that bought his/her content, so he can raise his syndication prices 6) Sites buying his content make money from ad banners 7) Profit!!
Well that's the problem - the reason MS bundles all their changes into earth-shaking releases every few years is so that everybody feels the need to upgrade. If you could just get Win2K plus a few (free) service packs and optional modules to get your app running, why buy the next release?
The downside of course is that people who don't want to / can't afford to pay for the upgrade just run the old buggy POS version and get hacked. Yeah, vendors have to cut off support sometime, but MS is not exactly a shining example of patch management (their backporting, QA, and automated installation are all pretty poor).
Apple is doing much more frequent releases and charging for all of them. It's probably annoying to some that they keep having to rev their applications, but the payoff is that when Apple ships a new OS, the changes aren't so dramatic that you have to sell a whole new app. There's the downside of having to ship a binary that works with OS 10.0-10.1, another for 10.2, and yet another for 10.3 (in some cases), but all of those binaries actually make money. Contrast that with years of dev builds compiled against an OS that nobody has, in hopes of eventually making some money when the damn OS rev ships. How much fun is it to keep those 2 code bases (old, shipping OS vs. new developer preview of OS) in sync and debugged? Once the new OS ships you can choose when to abandon the version of your app that targets the old OS, depending on how hard it is to backport patches (isolate OS calls that changed, so it's trivial?) and whether anybody's still buying the old version, and what you promised on your license agreement.
Now we just need to get Apple to stop charging so much for every release.:)
Mozilla was available to the public well before 1.0. It also changed quite a bit. Calling Mozilla 0.2 a "preview of Mozilla 1.0" would be pretty ridiculous.
It's ridiculous to ship APIs several years in advance. Yes, they will change in response to developer feedback, and that's good, but my point is that it's silly to call it a preview, and it's silly to even have a developer release that far ahead. You might as well call Mozilla 1.5 a preview of Mozilla 3.
>Microsoft hides their API's, they suck! Yup.
>Microsoft divulges their API's, they suck! Better than hiding them, but they're not really APIs to a product. They're APIs to a far far future product, which calls into question how useful they are.
Think about this: Microsoft ships a CD with a preview of their post-Longhorn OS, to ship in 2012. But you can get the APIs now! Awesome! And you can look at the screen shots to see what the UI will look like in 2012. Start porting your code now. That way, as you re-port your code to each successive developer release, when they change everything several times, you'll be so familiar with the APIs that you'll be able to write a book about all the shit that they never actually put in a general release, and won't that be wonderful. Managers should definitely invest lots of time in having their engineers port their apps to operating systems that don't exist, and won't ever exist in the currently documented form. That'll save them so much money!
You should have saved yourself the typing and just said "I didn't notice you were joking."
>It already runs on generic x86.
Mac OS X does not run on generic x86. I didn't specify, but you knew that's what I was talking about; don't pretend. The people bitching about Apple not porting its OS to x86 aren't going to use a bare Darwin system.
>I don't think Apple has the resource to write drivers for all the x86 hardware and hardware vendor will not do it either as they usually not do it for Linux.
Exactly! That's why I added the (e) troll in with my list...
>I read somewhere (don't remember where) that context switching are a lot more expensive on x86 than PowerPC.
Interesting! But my point was that for the stuff that most people do on the DESKTOP where bleeding-edge performance is required, they're not spending all their time in kernel calls (especially not lots of little ones); they're spending it in user space crunching data. OK, so if you benchmark a microkernel there's probably some overhead, but this is just another example of where geeks freak out about optimizing something unimportant in the larger performance picture.
Example: "god damn all these buffer overflow bugs, but I'll never use anything but C because I need maximum speed." Either you have time to track down all those bugs and write bulletproof code, or you should just move up one level of abstraction and program in an environment that burns some CPU time checking up after you at runtime. The extra time you have left over (from not having to debug all that buffer code that you wrote by hand with pointer arithmetic, because b4r3 m3t4l c0d3rz r00l!!) could be spend in actual performance testing of high-level functions, with a profiler, making high-level optimizations like not opening the same file 10000 times, or not calculating the same result 10000 times, etc. instead of just writing it all in C.
Likewise, unless folks KNOW that the microkernel is a major problem for their use of the OS, they should STFU. It's like bitching that the installer for an application isn't a true 64-bit program. Why doesn't the god damn installer use the SIMD instructions in my CPU? Waaaah!
>Mac OS X will run on non-Mac PowerPC hardware with Mac-on-Linux (because of drivers issues).
Awesome! So I can get the lower price/performance of a PPC processor, AND my hardware won't Just Work, AND I'll get no vendor support! Where do I sign?
> Why? Windows will run Windows apps and is pre-installed.
No shit. But that's one of the tired old gripes about Macs... "but there's all those apps that only run on Windows! I can't switch!" Combine that with an x86 Mac port (another gripe, remember?) and it's clear that the x86 port would have to run win32 apps to make people STFU.
>>(e) use Windows drivers >Why? Drivers are very OS specific.
Because as you mentioned, if there were an x86 port of Mac OS X, "nobody would write drivers". Of course, they write PPC drivers for Mac OS X, so it's not necessarily true that they wouldn't write them for x86. But again, the "port OS X to x86" folks are thinking of their l33t Opteron PC with all sorts of funky hardware, and chances are that won't all work with an imagined OS X x86 port. So why not cry about that too?
This is tiresome. I can't defend every stupid troll that I posted, because the whole point is that I was just repeating stupid trolls all at once to be even more shrill.
Well bully for you, but my point was that re-encoding movies is still a task that makes you wait, so people who are into movie "sharing" have an excuse for getting excited about faster CPUs. You've made my point about playback... if all you're doing is (sorta) watching a movie on your computer while you work, or while it's doing something else (downloading something?), there's no need for a new computer.
Since most people seem distracted by "why didn't he mention Mac OS X", I'd just like to be the first one to say that the transcript of this interview really sucks.
Linus has some interesting things to say but the number of typos and half-completed sentences make it hard to know how much more he actually said.
>I wish/.ers would check their facts before screaming how the sky is going to fall on our heads every time the USPTO grants a patent.
I wish/. ADMINS would RTFA and reject stupid submissions, or ones that were posted already, or ones that are months-old news (or more than one of these).
Story: Microsoft hit men kill RMS and Linus Admin: [approve] Poster: I can't believe this happened! Reply: You dummy, it's just a link to goatse! ...who's the dummy here? Who's GETTING PAID to keep the quality of content high?
You're forgetting about the gamers (you know, the people whose sigs always include their CPU. motherboard and video card specs) and movie "sharing" community. Games eat up CPU, but even more than that, DVD ripping and re-encoding to SVCD or whatever is brutal.
But you're right; for things that are worthwhile uses for a computer, almost no client-side apps make the user sit and wait for the computer to finish thinking. Nowadays power users run 10+ apps at a time, ripping and playing back MP3s, or maybe showing a movie in a window, and downloading a bunch of stuff at the same time. Even developers (previously the folks who could say "yeah but I have to compile my big studly app that takes 30 minutes on my big mofo desktop") now have tools that avoid the compile-from-scratch step in most cases.
What we really need is more bandwidth. DSL still costs exactly as much as it did 5 years ago. So do telephones. So do cable modems, although they aren't as retarded as they used to be (no more cable down + dialup return). Do that, and all of a sudden hoarding "shared' files doesn't make so much sense. Are you listening, RIAA and MPAA? Stop suing children and start suing telco monopolies for making video on demand over the internet such a pain in the ass just so they can make big bucks for their CEOs! Where's my 100MBps fiber for $20/mo? Why not?
Exactly, because Everybody Knows that microkernels are slow.
(Does it count as a troll if you're serious?)
Wait, let me see if I can connect some of them...
Microkernels being slow are the reason Macs are so much slower than PC's! And if Apple would just: (a) port to x86 (b) drop the microkernel in favor of Linux (c) allow clones (d) run Windows apps (e) use Windows drivers (f) eliminate their greedy 75% profit margins ... then Macs would take over the world!
Slashdot Mirror
This is good to know.
Still, the folks writing worms (so far) don't exhibit signs of being particularly knowledgeable about Windows. They're basically script kiddies who dare to break out Notepad and fiddle around a bit. I don't know of any source of statistics for failed worm writing attempts, so who knows what the ratio is of wannabe worm authors vs the ones who manage to make one that works.
My point is that even though a given security measure can be defeated by a determined & informed attacker, it may still be worth the effort if it turns away the script kiddies and worms. Most of us don't have anything that's worth a determined & informed attacker's time, whereas a worm doesn't care, and worm authors don't need to account for every possible situation; they attack the default configuration and ignore all the alternate possibilities.
If you mean "the JVM shouldn't interpret the same code each time it runs", it doesn't, or at least not exactly. It JIT-compiles the [frequently called parts of the] code once each time it runs, and then uses the native code from then on. If you kill and restart the JVM, though, it has to re-JIT-compile the code. I suppose a slightly faster mechanism would be to cache the compiled native code to disk, like (IIRC) NT on Alpha did for x86 DLLs, or as .NET's CLR does. But I have yet to see an application that was stymied by JIT compilation overhead - more commonly the problems are overall JVM startup time, JVM memory overhead, or algorithmic mistakes that lead to extreme garbage collection overhead or memory "leaks" (forgotten references that the GC assumes are important).
i sc/apple tcaching.html
If you mean "it's stupid to load the code from the network every time", the Java Plug-in has done this for over three years:
http://java.sun.com/j2se/1.3/docs/guide/m
Yeah, I've been waiting for that to work for several years now. Still waiting.
Did you miss the part where he said 90" diagonal? You might as well say that he's foolish for spending any more than $99 because you have a mini TV that cost that much.
I'm not trying to make this a Size Matters thing any more than it needs to be. But compare like to like - a 60" rear projection TV runs more like $4500, and is a bastard to get up and down stairs. A few years ago when I bought my LCD projector, Fry's (a local chain in Silicon Valley) was selling a 70" projection-screen TV for $8000.
BTW folks, bear in mind that if you have a home theater and NetFlix, you'll save a TON on things like movie tickets, candy/popcorn, gas, etc. My wife and I have been to the movies three times this year. How much do you spend on going out to the movies every year? (It doesn't have to be a super deluxe home theater, either, no matter what the freaks who spend $30,000 on home theater setups would have you believe.)
First they ignore you.
Then you're dying.
Then you're beleaguered.
Then you stay beleaguered.
Already been done:
http://www.openmusicproject.net/
Can I just skip listening to it altogether?
Everything since (and possibly including) the None More Black album has been craptacular.
That's not a sufficient argument to counter the audiophiles. At the heart of the audiophile point of view is the idea that their ears are superior (innately, or through training) and that they need special ultra-high-end equipment in order to get the maximum enjoyment out of music - enjoyment which vastly exceeds that of the typical listener with plan old hearing on consumer grade equipment.
I think I'll start trolling with complaints about how I can see well into the infrared and ultraviolet spectrum, and that I will settle for nothing less than original film copies of movies because analog film accidentally captures infrared and ultraviolet images as well (even though no one else can see it). HDTV just ruins movies that are better appreciated in film form! Also, glass lenses have a very negative impact on the quality of light, so I only use diamond lenses in my projectors. And to avoid jitter in the frames, the sprockets in my projector are made of titanium so there's no chance that they will wear down over time and fail to grasp the film perfectly.
Sorry dude. Sonic Youth is inherently lossy. Re-encoding them at 96Kbps sounds exactly the same. :)
Welcome to Slashdot. Obviously you haven't been here long if you're not pathologically obsessed with Mozilla and ogg vorbis. :)
If applets worked better they'd be abused for ads too!
It's not the computers, it's the users that bog down the non-CS IT departments. You're overlooking the size and skill level of the user base.
CS students (who have gotten past the Freshman level weed-out courses) are likely to me MUCH more tech savvy than, say, a music or statistics major (who mainly want to just run one or two applications and then read email and surf).
Compare that small group of highly technical users, who probably have owned computers for years and years and are embarassed to have to ask for help with printing, etc. (RTFM!), with the hordes of "mundanes" who just have to write a freakin' paper and don't know what "PC Load Letter" means on the printer or why opening attachments is dangerous.
>CS and EE departments make punishing use of their computing resources.
By which you mean, power users run programs that use a lot of CPU resources. Ooo, scary! Non-CS students physically break computers because they don't know better or don't care:
I need more RAM, I think I'll steal it out of a lab computer.
Hey what's this attachment, hey it doesn't seem to be doing anything, hmm now this computer's slow, oh well who cares, I'll use the next one.
Oops, I spilled my coke in the keyboard. I better not tell anybody or I'll have to pay for a new keyboard, and I bet that's expensive.
How nice that they built a cup holder into the front of this computer. Oops, I spilled my coffee into the cup holder opening.
I'm late for class, this printer is slow, maybe if I yank on the paper as it comes out, it'll print faster. Oops, paper jam, I'm outta here.
I love Napster! I think I'll download a bunch more file sharing apps and run them all the time since all my bandwidth is free.
This 22MB MPEG is soooo funny. I think I'll email it to everybody I have an email address for.
Also, we're offering TRIPLE that much for an OS that doesn't run IIS, DCOM, SQL Server, or IE 6.
:)
Any takers?
>I've worked quite extensively on an ERP application called PeopleSoft. It locates all of it's business logic in the middle tier. The SQL it produces is very database agnostic and will run with minor modification on most database platforms.
The folks I know who have implemented PeopleSoft at Fortune 500 companies complain bitterly about how it's terribly slow even on monster hardware, specifically because it is written to be so database-agnostic. This is not anything to brag about, and is certainly not an indicator that this is a good way to design something. Maybe it made sense for PeopleSoft to be portable at the expense of writing redundant code in the app that's already in major RDBMS products, AND making the app slower by running code in the app tier when it would run faster in the DB tier, but that doesn't mean that this is a good idea in general. Heck, it might even be a plain mistake on PeopleSoft's part that they have just had to live with.
BTW, I'm assuming a connection between two parts of your message here, but... a 10 CPU database server just to achieve hundreds of concurrent users, for an app that deliberately avoids running any code in the database tier? Ouch!
You may have already thought of this, but it probably would be helpful to factor out your persistence layer even though you're not expecting to need another back-end soon. It's cool to be able to make a persistence test harness (test your stored procs instead of your whole app, reducing the LOC you have to look through for each bug) even if you don't need another back-end.
OTOH, in a project that's actually funded, sometimes it's better to just hack something, QA it until it works, and ship it, and fix the internal ickiness (that slows developers down) later.
> Personally though I don't understand why application developers use a database for anything other than storage.
Clearly. But what does storage entail? Transactions? Backup? Concurrent access that works properly in all situations? Availability? Scalability?
> If all you are doing is simple inserts, selects, updates and deletes it should be very easy, if not trivial to make the application database independent.
Great! OK, so what if you AREN'T doing simple inserts, selects, updates, and deletes? If all you do is read and write data from the disk, why even use a database? Just use flat files! Woo hoo!
>Stored procs, triggers, etc, are evil
Exactly. It's much better to put all the persistence logic in the business layer, and make the database stupid so that it can't be clustered. That works way better. I always say, time-tested code can't hold a candle to my team of underpaid sweaty CS dropouts rolling something on their own! Or better yet, they can just overlook all the tricky situations they don't understand, and fix it later when it's in production and loses real data!
>as they spread your application logic all over the place
Because as we all know, single-tier architectures are the wave of the future. It's always better to write all of your code in The One True Programming Language that the alpha coder on the project happens to like, and run it all in one process in one tier.
> and there are no standards for how they are implemented by different vendors. It's hard enough to find a relatively standard subset of SQL semantics.
I'm not sure that there are *no* standards, but practically, it makes more sense to just encapsulate the persistence code for specific database back-ends, and write product-specific code for each back end. If you actually separate persistence logic out from business logic, this isn't very much work, and you can also attach a test harness to the back-ends and make sure they all work properly (reducing the likelihood of having lots of unique bugs in each back end).
Personally I tend to lean on triggers and referential integrity constraints (redundant rule enforcement is GOOD) more than stored procedures, but there are some other things in Oracle (or MS SQL 2K, or DB/2) that aren't in, say, MySQL, and these things are not just silly superfluous features that should be ignored in favor of hand-written replacements in PHP or whatever.
Hmm, that sounds suspicously like
1) Author makes content
2) Author makes content on crappy old 486 because they're essentially free now
3) Artists offers content for syndication
4) Lots of web sites buy author's syndicated content
5) Author gets popular, driving more traffic to sites that bought his/her content, so he can raise his syndication prices
6) Sites buying his content make money from ad banners
7) Profit!!
And we all know how well that worked out.
Well that's the problem - the reason MS bundles all their changes into earth-shaking releases every few years is so that everybody feels the need to upgrade. If you could just get Win2K plus a few (free) service packs and optional modules to get your app running, why buy the next release?
:)
The downside of course is that people who don't want to / can't afford to pay for the upgrade just run the old buggy POS version and get hacked. Yeah, vendors have to cut off support sometime, but MS is not exactly a shining example of patch management (their backporting, QA, and automated installation are all pretty poor).
Apple is doing much more frequent releases and charging for all of them. It's probably annoying to some that they keep having to rev their applications, but the payoff is that when Apple ships a new OS, the changes aren't so dramatic that you have to sell a whole new app. There's the downside of having to ship a binary that works with OS 10.0-10.1, another for 10.2, and yet another for 10.3 (in some cases), but all of those binaries actually make money. Contrast that with years of dev builds compiled against an OS that nobody has, in hopes of eventually making some money when the damn OS rev ships. How much fun is it to keep those 2 code bases (old, shipping OS vs. new developer preview of OS) in sync and debugged? Once the new OS ships you can choose when to abandon the version of your app that targets the old OS, depending on how hard it is to backport patches (isolate OS calls that changed, so it's trivial?) and whether anybody's still buying the old version, and what you promised on your license agreement.
Now we just need to get Apple to stop charging so much for every release.
Mozilla was available to the public well before 1.0. It also changed quite a bit. Calling Mozilla 0.2 a "preview of Mozilla 1.0" would be pretty ridiculous.
It's ridiculous to ship APIs several years in advance. Yes, they will change in response to developer feedback, and that's good, but my point is that it's silly to call it a preview, and it's silly to even have a developer release that far ahead. You might as well call Mozilla 1.5 a preview of Mozilla 3.
>Microsoft hides their API's, they suck!
Yup.
>Microsoft divulges their API's, they suck!
Better than hiding them, but they're not really APIs to a product. They're APIs to a far far future product, which calls into question how useful they are.
Think about this: Microsoft ships a CD with a preview of their post-Longhorn OS, to ship in 2012. But you can get the APIs now! Awesome! And you can look at the screen shots to see what the UI will look like in 2012. Start porting your code now. That way, as you re-port your code to each successive developer release, when they change everything several times, you'll be so familiar with the APIs that you'll be able to write a book about all the shit that they never actually put in a general release, and won't that be wonderful. Managers should definitely invest lots of time in having their engineers port their apps to operating systems that don't exist, and won't ever exist in the currently documented form. That'll save them so much money!
You should have saved yourself the typing and just said "I didn't notice you were joking."
>It already runs on generic x86.
Mac OS X does not run on generic x86. I didn't specify, but you knew that's what I was talking about; don't pretend. The people bitching about Apple not porting its OS to x86 aren't going to use a bare Darwin system.
>I don't think Apple has the resource to write drivers for all the x86 hardware and hardware vendor will not do it either as they usually not do it for Linux.
Exactly! That's why I added the (e) troll in with my list...
>I read somewhere (don't remember where) that context switching are a lot more expensive on x86 than PowerPC.
Interesting! But my point was that for the stuff that most people do on the DESKTOP where bleeding-edge performance is required, they're not spending all their time in kernel calls (especially not lots of little ones); they're spending it in user space crunching data. OK, so if you benchmark a microkernel there's probably some overhead, but this is just another example of where geeks freak out about optimizing something unimportant in the larger performance picture.
Example: "god damn all these buffer overflow bugs, but I'll never use anything but C because I need maximum speed." Either you have time to track down all those bugs and write bulletproof code, or you should just move up one level of abstraction and program in an environment that burns some CPU time checking up after you at runtime. The extra time you have left over (from not having to debug all that buffer code that you wrote by hand with pointer arithmetic, because b4r3 m3t4l c0d3rz r00l!!) could be spend in actual performance testing of high-level functions, with a profiler, making high-level optimizations like not opening the same file 10000 times, or not calculating the same result 10000 times, etc. instead of just writing it all in C.
Likewise, unless folks KNOW that the microkernel is a major problem for their use of the OS, they should STFU. It's like bitching that the installer for an application isn't a true 64-bit program. Why doesn't the god damn installer use the SIMD instructions in my CPU? Waaaah!
>Mac OS X will run on non-Mac PowerPC hardware with Mac-on-Linux (because of drivers issues).
Awesome! So I can get the lower price/performance of a PPC processor, AND my hardware won't Just Work, AND I'll get no vendor support! Where do I sign?
> Why? Windows will run Windows apps and is pre-installed.
No shit. But that's one of the tired old gripes about Macs... "but there's all those apps that only run on Windows! I can't switch!" Combine that with an x86 Mac port (another gripe, remember?) and it's clear that the x86 port would have to run win32 apps to make people STFU.
>>(e) use Windows drivers
>Why? Drivers are very OS specific.
Because as you mentioned, if there were an x86 port of Mac OS X, "nobody would write drivers". Of course, they write PPC drivers for Mac OS X, so it's not necessarily true that they wouldn't write them for x86. But again, the "port OS X to x86" folks are thinking of their l33t Opteron PC with all sorts of funky hardware, and chances are that won't all work with an imagined OS X x86 port. So why not cry about that too?
This is tiresome. I can't defend every stupid troll that I posted, because the whole point is that I was just repeating stupid trolls all at once to be even more shrill.
Well bully for you, but my point was that re-encoding movies is still a task that makes you wait, so people who are into movie "sharing" have an excuse for getting excited about faster CPUs. You've made my point about playback... if all you're doing is (sorta) watching a movie on your computer while you work, or while it's doing something else (downloading something?), there's no need for a new computer.
Since most people seem distracted by "why didn't he mention Mac OS X", I'd just like to be the first one to say that the transcript of this interview really sucks.
Linus has some interesting things to say but the number of typos and half-completed sentences make it hard to know how much more he actually said.
Is there another transcription somewhere?
>I wish /.ers would check their facts before screaming how the sky is going to fall on our heads every time the USPTO grants a patent.
/. ADMINS would RTFA and reject stupid submissions, or ones that were posted already, or ones that are months-old news (or more than one of these).
...who's the dummy here? Who's GETTING PAID to keep the quality of content high?
I wish
Story: Microsoft hit men kill RMS and Linus
Admin: [approve]
Poster: I can't believe this happened!
Reply: You dummy, it's just a link to goatse!
You're forgetting about the gamers (you know, the people whose sigs always include their CPU. motherboard and video card specs) and movie "sharing" community. Games eat up CPU, but even more than that, DVD ripping and re-encoding to SVCD or whatever is brutal.
But you're right; for things that are worthwhile uses for a computer, almost no client-side apps make the user sit and wait for the computer to finish thinking. Nowadays power users run 10+ apps at a time, ripping and playing back MP3s, or maybe showing a movie in a window, and downloading a bunch of stuff at the same time. Even developers (previously the folks who could say "yeah but I have to compile my big studly app that takes 30 minutes on my big mofo desktop") now have tools that avoid the compile-from-scratch step in most cases.
What we really need is more bandwidth. DSL still costs exactly as much as it did 5 years ago. So do telephones. So do cable modems, although they aren't as retarded as they used to be (no more cable down + dialup return). Do that, and all of a sudden hoarding "shared' files doesn't make so much sense. Are you listening, RIAA and MPAA? Stop suing children and start suing telco monopolies for making video on demand over the internet such a pain in the ass just so they can make big bucks for their CEOs! Where's my 100MBps fiber for $20/mo? Why not?
Exactly, because Everybody Knows that microkernels are slow.
... then Macs would take over the world!
(Does it count as a troll if you're serious?)
Wait, let me see if I can connect some of them...
Microkernels being slow are the reason Macs are so much slower than PC's! And if Apple would just:
(a) port to x86
(b) drop the microkernel in favor of Linux
(c) allow clones
(d) run Windows apps
(e) use Windows drivers
(f) eliminate their greedy 75% profit margins
Hey, this is fun!