So I'm supposed to design my page so I show PNGs to people who can handle them, and GIFs to people who can't?
Well, that definitely improves the user experience for people with modern browsers, but it doesn't help with the patent issues at all. If I have the GIFs on my site and server them to some of my customers, I'm using UniSys's patented technology, and I'm screwed.
The only solution is to ditch GIF entirely. And I'd love to see it happen, but after years of predictions, it hasn't happened yet.
One major advantage of PNG that you left out: PNG can handle 32-bit images. Actually, it can handle 16 bits/channel RGB plus 8 bits of alpha, or almost any other sensible combination you can think of.
PNG's biggest disadvantage is lackluster browser support. 8-bit or 16-bit alpha is much cooler than 1-bit transparency--but many browsers don't handle it properly, and some don't even handle PNG's 1-bit transparency properly right, so it's not usable.
As for animation, others have already commented on MNG. Check it out; it's spiffy. But no browsers support it yet.
It would be nice if that were true, but people have been saying this for years, and it hasn't happened yet. There are still far more GIFs than PNGs on the net. And there are some good reasons for this.
Most browsers still don't support PNG properly. If you create a proper GIF and use it properly on your web page, just about every browser ever written will handle it the way you expect. The same isn't true of PNG.
PNG doesn't do animation. Recently, the PNG family has included a format called MNG that can do all kinds of cool stuff with animation. But very few browsers have any way to display MNG animations, while most can display GIF animations.
While PNG has kick-ass support for transparency (16-bit alpha with background color, background image, or "whatever's behind me"), it doesn't work in many browsers.
There are a lot more tools for creating, playing with, optimizing, using on the web, etc. GIFs than PNGs. For example, some WYSIWYG web page editors will let you drop any image in some other format (TIFF, for example) onto your web page, and silently convert it to a nicely-optimized GIF, put it in the right place, and write the HTML to insert it yourself. I don't know of any that will automagically do all of this with a PNG. (Note: I'm not saying people _should_ use such crappy tools when they could just use convert on their image to make a PNG and insert the tag in emacs, or export as a PNG in PhotoShop and import it properly in their tool, or whatever--I'm saying people _do_ use such crappy tools.)
Finally, for some really small 8-bit images, a GIF actually is smaller than a PNG. (Of course the vast majority of images are smaller as a PNG, even with 16-bit high-color instead of 8-bit palette color....)
I'd love to see the GIF format die a quick death and PNG/MNG/JNG take over the universe, but wishing doesn't make it happen.
All clients are PNG-capable? Well, the most recent versions of most browsers have some PNG support, but none of them seem to be that good.
As an example, I tested Netscape 4.7 under linuxppc with some PNG test suites (start at http://www.cdrom.com/pub/png/pngsuite.html), and it has a number of problems.
1. It doesn't handle alpha transparency right (it alpha-composites with the image's default background color, rather than whatever's behind the image).
2. It often handles alpha as all-or-nothing (I can't seem to find a consistent pattern).
3. It doesn't handle gamma properly--actually, at all.
4. It ignores pixel sizes and shapes.
5. It does odd things with 16 bits/channel images.
6. It doesn't progressively display interlaced images.
7. If you use palettes and alpha in the same image, you sometimes get garbage.
8. Illegal images sometimes just don't show up, rather than showing up as "broken" images.
Also, some newer features of PNG (like animation) are missing.
As long as you're careful, you can still use PNGs to do everything GIFs can do except animation. But nonetheless, we're obviously still a long way from universal PNG support.
As for animation, the only way I can think of replacing animated GIFs on a website and making it accessible to most browsers is to use multiple PNGs with JavaScript or Java. Obviously not a great solution.
Well, Opera still doesn't run on non-x86 linux. Or linux 2.0, 2.1, or 2.3/2.4. Or Debian-based linux 2.2.
And while they are "actively persuing" ports, they apparently don't intend to ever have it working on all platforms (e.g., my PowerPC 604e).
I wish someone could convince the iCab developers that they're wrong about linux ("we believe that the graphical interface of Linux is not very good (compared to the Mac)"), but for now, my only real choices are Netscape 4.7 or Mozilla....
As much as I hate defending Microsoft (and by the way, Windows trolls see plenty of alpha software... it's just called "release version" instead of "alpha"), I have to say this:
Microsoft's Mac version of IE 4.0 was a complete rewrite from scratch, and it was slick as hell and far more stable than any Mac version of Netscape or Mozilla (or the previous versions of IE for the Mac, of course).
Also, Opera and iCab were brand new browsers, written from scratch, and their pre-release versions were pretty solid.
The problem here isn't that it's a total rewrite, it's that it's an incredibly ambitious rewrite. Maybe it would have been better to release a 5.0 based on the pre-Gecko engine just to get something useful out the door so people wouldn't have as much to bitch about?
If IE5.5 really does follow the entire DHTML standard (which I believe they claim it will), people will probably eventually recode their pages to follow the standard. But if it doesn't (and Microsoft doesn't always live up to their prerelease claims...), many web developers won't.
Most people I know who make web pages try them with Netscape 4.7 and IE 4.5 on their Macs, and maybe IE 5.0 on Windows if they have a Windows box lying around. If they work there, that's good enough....
Personally, I try to make sure things look good on every reasonably recent version of IE, Netscape, iCab, and Opera on every platform I can find, and even check to make sure it's at least usable with lynx, but I'm not typical.
Yes, Netscape 6PR1 is a (pre-)beta, and people shouldn't expect too much yet. But compare it to the IE 5.5 beta, or the iCab 1.9 alpha, and it looks very unfinished. (I would comment on M15, but there's no linuxppc version yet....)
The public perception may be unfair (I mean, look at the first IE4 preview release...), but that doesn't mean you can ignore it. When you release a product to the public like this, they're not going to read all the warnings--they're going to download it and try it out. And if they don't like it, they're going to be turned off.
Netscape and IE are both based partially on Mosaic. And I always though the name meant something like "kick-ass Godzilla-style version of Mosaic," not "Mosaic killer," but I could be wrong.
And Godzilla isn't a dinosaur, so they're obviously cashing in on the most famous dinosaur around, Barney.
More interesting is the fact that Microsoft started identifying IE as "Mozilla" in the user-agent field (so pages that had Netscape-specific features that were only active with the right user agent would show up spiffy in IE).
I still haven't figured out what "Opera" and "iCab" are supposed to mean. And NetPositive almost sounds like it means something, but then you realize that it doesn't....
If you really want to be accurate, Windows 2000 is missing half the features that NT 5.0 was supposed to have (and that were half-way done in the beta).
And by the way, MacOS X, GNOME, and KDE don't bear much code resemblance to MacOS 7, AnotherLevel, or AfterStep either....
When's the last time you used a 10-year-old laptop?
First you'd have to remember how to use GNOME 1.0 or MacOS 9 or Windows 98.
Then you'd spend the rest of the day cursing the 366MHz CPU, the tiny 8GB hard drive and 128MB memory.
The chunky 1024x768 resolution that only works from a narrow angle would really bother you. Plus the old-fashioned keyboard--layouts change in 10 years (if we're even still using flat QWERTY-based key arrays)
And what's the chance the trackball or touchpad or thumb thingy would even work after 10 years of dust collecting? And will people still use such things anyway? I used to be perfectly happy navigating windows with a joystick on an Apple//gs, but I can't imagine doing it now.
Then you'd remember that it can't connect to the net without some kind of Ethernet thingy connected to DSL or Cable, whatever those are. After a few hours of futzing around, you'd get it connected, and it would run off to your homepage.
So after it tried to hit an IPv4 nameserver to look up the old-style DNS name slashdot.org, you'd spend the next few hours actually getting it connected to the right place. Where it would try to load the page customized for your old account, which hasn't been used in 8 years.
Of course your browser won't support any HTML 9.0 features, but good old/. will still be useful with an HTML 4.0 browser, and all your old slashboxes will come up. So you can finally get to the latest episode of Sluggy Freelance.
But come on, will Sluggy still be funny after all those years? Pete's good, but he's no Walt Kelly....
Another reason suspending is useful for desktops: There are times when you need to disconnect the plug.
For example, yesterday, I moved my computer to a new UPS. To do this, I had to power down, unplug the computer, plug into the UPS, power up, and go through the whole boot sequence. If I could just suspend, unplug, plug in, and wake, like a laptop, it would have been more convenient. And it would have meant 2 seconds downtime for my server instead of 2 minutes.
It's not just that. The problem is, people want more and more complicated software--and as it becomes more and more complicated, it also becomes more unstable, inefficient, etc.
Yes, Windows 2000 is even slower and clumsier than Windows 95. But compare GNOME, KDE, and MacOS 9.0 to AnotherLevel, AfterStep, and MacOS 7.5. In every case, they're much bigger, much slower, and less stable.
So why do we continue to upgrade? TWM came preinstalled with my distribution, and yet I never use it.
Part of it is just the spiffiness issue. As Steve Jobs said in explanation of the glowing buttons in Aqua, "Well, when you've got a gigaflop to play with...." My GNOME desktop looks much better than my first X desktop--and most of the apps I run fit in with it pretty well. Plus, Falco dances along to the music when I play MP3s!
For that matter, I can now play MP3s, even mix two at a time. I can edit huge graphics files with GIMP. I have 4 times the pixels at 4 times the color depth and 20 times the net bandwidth, and everything still works smoothly.
And then there's usability. I could ramble on about how nice it is to be able to browse SMB shares, and drag an MP3 onto an XMMS playlist, but there's a much better indicator. My roommate, who's never used anything other than Win9x and MacOS 8/9 was able to sit down at the computer and figure out Netscape, GnomeICU, GEdit, the file manager, etc. within a few hours, with no help. When I tried to get a former roommate to use linux a couple of years ago, she ran screaming from the room....
So yeah, ESD and GNOME and imwheel and so on are slowing down my computer, but I still use them, and I'm sure a lot of other people do. And they make my extra CPU power useful for more than just compiles and games....
Adding to #1, on MacOS, there are a lot of games that use other parts of GameSprockets without using DrawSprockets. There are a lot of games that use standard QuickDraw drawing, but that I can play with my barely-supported joystick thanks to InputSprockets.
There are also cheesy freeware games that have 1986-style graphics, but have network play, 3D sound, and other spiffy GameSprockets features.
A separate thought: it would ideally be as easy as possible for hardware vendors who'd already written DirectX drivers to write Khronos drivers. The question is, how do you do that? Maybe have a "DirectX emualting" driver shell which can plug into Khronos as a driver, but presents a very DirectX-like driver-side API for the hardware vendor. A driver built this way wouldn't be as good as a native driver... but it'd be better than nothing.
Re:Not likely in the near future, but why not?
on
Linux on the Brain
·
· Score: 1
"Several orders of magnitude." Well, that's no big deal. Each order of magnitude is, what, 5 years (log 2 10 * 1.5)? So we're talking about 10-15 years until we have the technology?
The big issue is probably not the hardware; it's the training. You can build a huge, kick-ass neural network, but it'll still take a lot of training to do anything useful. Remember that our brain has connections that were made over decades of life, and millenia of evolution. A neural network connected up from scratch won't have that until you train it.
A capacity of 100GB is cheap. Gathering 100GB of data is not.
It's similar to the big problem with traditional (non-connectionist) AI. Who cares if a computer is as powerful as a human brain, if it doesn't have any useful knowledge. Projects like "CYC" have spent years trying to gather enough "common knowledge" information to make a useful AI, but they're nowhere near done.
OK, that's a good point. Monarchs got to collect the taxes and write the laws, and the system ended up perpetuating monarchy.
But if you look at the long run, what eventually happened in nearly every case is that local feudal lords were able to amass more money than the absolute monarchs, and restructure power for their benefit.
Later, the bourgeousie were able to amass more money than the feudal lords, and restructure power for their benefit.
More recently, corporate wealth has far outstripped individual wealth, and the system is being restructured for their benefit.
So things are always changing. Maybe "the more things change, the more they stay the same" as long as "the masses" aren't the ones with the money and power, but still, having money today doesn't guarantee that you're going to have it tomorrow.
OK, as a PPC bigot (well, an anti-x86 bigot) who owns a PPC linux box and two ancient x86 boxes (a P200 and a 486DX2/66), I'll express some interest. I think the best proposal is this:
Instead of a VM, write a cross-platform x86 linux emulator. All system calls run "native;" all x86 instructions are emulated.
Of course I'd prefer a native PPC app over an emulated x86 app, but I'd prefer an emulated x86 app to nothing at all. In the same way that I'd prefer a native linuxppc port to a Mac app under mol, but I prefer mol to not being able to run those apps at all.
Maybe we could even devise a VM that just happens to map instructions one-to-one to x86 instructions. Would this be significantly slower on an x86 than a native x86 app? How much faster would it be on an x86 than a VM designed from scratch? And how much slower would such a VM be on my PPC than a VM designed from scratch? (Another question: Would apps run better in the Itanium implementation of the VM, or in "native" x86 emulation mode?)
By the way, DEC didn't just do some work--they had a 99% functional x86 emulator that was included in NT 4.0 for Alpha. Most apps than ran under NT 4.0 for x86 ran under the emulator--sometimes even faster than on an equivalent-MHz Intel box (sometimes much slower, as well...).
Interestingly, the programs I remember not working were nearly all Microsoft programs, most of which coincidentally had NT Alpha versions (so you had to buy an extra copy, for more money, if you wanted to run it on both...).
But Microsoft abandoned NT Alpha, and I assume DEC abandoned the x86 emulation layer.
Yeah, sure, most of us PPC linux users can just reboot to MacOS (or run mol). But can't most x86 linux users reboot to whatever came preinstalled on their machine (or run vmware or WINE)?
Plus, there are some PPC linux users that aren't using a PowerMac. And some who don't have MacOS on their machine. And what about Sparc and Alpha and ARM and so on?
This will always be a problem with binary-only releases. A source release can be used with every platform out there (unless it uses x86 assembly code or kernel internels from a specific version or something--as a lot of the video stuff does). A binary release often comes out for only one platform, or only the three official RedHat platforms, or only x86 and PPC, etc.--because those are the only machines the company has.
WINE and WineLib just increase the problem.
I have a few x86 linux boxes around. Even though my PPC box is much faster, sometimes I have to run things on one of the Pentiums. Good thing X works, eh?
MacOS isn't a Microsoft OS, and IE 4.5 or 5.0 clobbers Netscape 4.x in every way--speed, stability, size, standards implementation, flexibility, and features. Plus, Steve Jobs told me to use it. (Actually, I use iCab 1.9 more often than either, as it's the only one that hasn't yet crashed my computer.)
The one area where Netscape beats IE is in platform support. IE runs on only Windows, MacOS, and a few Unixes, and it's wildly different on each platform. Netscape 4.7 runs pretty much the same under LinuxPPC as under MacOS, which is pretty nifty.
So what about Netscape 6.0? Well, it closes the gap in some areas, and goes even farther with its multiple platform support--plus, it's based on open source code. But for MacOS or Windows, IE is still better as an everyday browser. Sorry.
First, if you're fired for refusing to comply with an illegal order, you can sue for wrongful termination. And they know this, so you can just threaten it. Of course you'll want to start looking for a new job, but they're not going to fire you for that, or you can sue for retaliation.
For that matter, once you start looking for a new job, you have lots of options. Put the backdoor in as ordered and then tell everyone about it anonymously. Make the backdoor not work. Go way over schedule in implementing it.
And if you're working as a programmer at a major company, you're making enough money that you ought to be able to just quit and support your family for a few weeks while you look for a new job (and cool off your anger).
As for the one hour--well, if all you care about is money, sure, but if I just had to quit a job over something like that, I'd be looking a little more carefully at my next employer....
"You can't be absolutely complacent, unless you both compile everything on your system from source and review all the source code before compiling."
True. And even that doesn't help--unless, of course, you're absolutely perfect and there's no way a bug, backdoor, or easter egg could slip past you.
But you can feel much _more_ secure with open-source software than closed-source, even if you don't study the source, or even compile it yourself. Because you know that other people have compiled it (at the very least, whoever built the.ppc.rpm and.deb packages...) and likely some people have looked it over. Whereas with Microsoft's source, you know for sure that nobody outside of Microsoft (and companies that have signed NDAs with Microsoft) has seen the source.
When Microsoft releases something, they know people are going to hammer it and try to crash it, penetrate it, or otherwise make it fail. And their software is probably better than it would have otherwise been for this (scary thought, eh?). But they also know that nobody's going to recompile the source, much less study it. And their software is definitely worse than it could have been for this.
But these _are_ benchmarks. Anything that you can test on multiple machines to compare them is a benchmark. And they can be "faked" in the same was as any benchmark--by improving your hardware, drivers, software, etc. for these particular uses.
However, if this is the kind of thing you do all the time, then it's to your benefit if someone tweaks their hardware to improve it.
Apple, with help from Adobe, has gone out of their way to make often-benchmarked Photoshop tests run faster on their machines. But this same effort also makes my actual work with Photoshop go faster--so I have no complaints.
Unfortunately, the end result of optimizing one task may be that other tasks, like starting up Netscape or scrolling in Word, aren't as fast as they could be. Maybe that doesn't matter to you; maybe it does.
The compilation test is a little more problematic. It's very easy to make a compiler run faster by not making the ultimate compiled code slower, or even less accurate. That's obviously something you wouldn't be happy with.
The only way that'll give you any information is if you actually research all the benchmarks.
Imagine you're comparing, say, the IBM and Motorola next versions of the PowerPC. They both advertise benchmarks where they clobber each other. In Motorola's case, they're using lots of stuff that takes advantage of Altivec; in IBM's, they're using lots of stuff that takes advantage of parallelism with multiple cores. If you go read the benchmarks and what they were designed for, then maybe you have enough information to figure out that for your usage, two chips with Altivec is better for you than a single double-core chip without Altivec, or vice-versa. But you could probably figure that out without even looking at benchmarks....
But what is a non-biased test going to do in a situation like that? How much is the "right" amount of FPU usage for the test? Or 128-bit vector processing? It really depends on what you do.
I don't think you can do better than specific application tests. If I spend most of my time waiting for a certain set of GIMP filters to do their thing, what could possibly be a better test for me than one that exercizes those filters, on the types of images that I most often?
So an ideal test would have to contain a huge variety of application subtests, and hopefully everyone could look at the particular subtests they care about.
Slashdot Mirror
So I'm supposed to design my page so I show PNGs to people who can handle them, and GIFs to people who can't?
Well, that definitely improves the user experience for people with modern browsers, but it doesn't help with the patent issues at all. If I have the GIFs on my site and server them to some of my customers, I'm using UniSys's patented technology, and I'm screwed.
The only solution is to ditch GIF entirely. And I'd love to see it happen, but after years of predictions, it hasn't happened yet.
One major advantage of PNG that you left out: PNG can handle 32-bit images. Actually, it can handle 16 bits/channel RGB plus 8 bits of alpha, or almost any other sensible combination you can think of.
PNG's biggest disadvantage is lackluster browser support. 8-bit or 16-bit alpha is much cooler than 1-bit transparency--but many browsers don't handle it properly, and some don't even handle PNG's 1-bit transparency properly right, so it's not usable.
As for animation, others have already commented on MNG. Check it out; it's spiffy. But no browsers support it yet.
It would be nice if that were true, but people have been saying this for years, and it hasn't happened yet. There are still far more GIFs than PNGs on the net. And there are some good reasons for this.
Most browsers still don't support PNG properly. If you create a proper GIF and use it properly on your web page, just about every browser ever written will handle it the way you expect. The same isn't true of PNG.
PNG doesn't do animation. Recently, the PNG family has included a format called MNG that can do all kinds of cool stuff with animation. But very few browsers have any way to display MNG animations, while most can display GIF animations.
While PNG has kick-ass support for transparency (16-bit alpha with background color, background image, or "whatever's behind me"), it doesn't work in many browsers.
There are a lot more tools for creating, playing with, optimizing, using on the web, etc. GIFs than PNGs. For example, some WYSIWYG web page editors will let you drop any image in some other format (TIFF, for example) onto your web page, and silently convert it to a nicely-optimized GIF, put it in the right place, and write the HTML to insert it yourself. I don't know of any that will automagically do all of this with a PNG. (Note: I'm not saying people _should_ use such crappy tools when they could just use convert on their image to make a PNG and insert the tag in emacs, or export as a PNG in PhotoShop and import it properly in their tool, or whatever--I'm saying people _do_ use such crappy tools.)
Finally, for some really small 8-bit images, a GIF actually is smaller than a PNG. (Of course the vast majority of images are smaller as a PNG, even with 16-bit high-color instead of 8-bit palette color....)
I'd love to see the GIF format die a quick death and PNG/MNG/JNG take over the universe, but wishing doesn't make it happen.
All clients are PNG-capable? Well, the most recent versions of most browsers have some PNG support, but none of them seem to be that good.
As an example, I tested Netscape 4.7 under linuxppc with some PNG test suites (start at http://www.cdrom.com/pub/png/pngsuite.html), and it has a number of problems.
1. It doesn't handle alpha transparency right (it alpha-composites with the image's default background color, rather than whatever's behind the image).
2. It often handles alpha as all-or-nothing (I can't seem to find a consistent pattern).
3. It doesn't handle gamma properly--actually, at all.
4. It ignores pixel sizes and shapes.
5. It does odd things with 16 bits/channel images.
6. It doesn't progressively display interlaced images.
7. If you use palettes and alpha in the same image, you sometimes get garbage.
8. Illegal images sometimes just don't show up, rather than showing up as "broken" images.
Also, some newer features of PNG (like animation) are missing.
As long as you're careful, you can still use PNGs to do everything GIFs can do except animation. But nonetheless, we're obviously still a long way from universal PNG support.
As for animation, the only way I can think of replacing animated GIFs on a website and making it accessible to most browsers is to use multiple PNGs with JavaScript or Java. Obviously not a great solution.
Well, Opera still doesn't run on non-x86 linux. Or linux 2.0, 2.1, or 2.3/2.4. Or Debian-based linux 2.2.
And while they are "actively persuing" ports, they apparently don't intend to ever have it working on all platforms (e.g., my PowerPC 604e).
I wish someone could convince the iCab developers that they're wrong about linux ("we believe that the graphical interface of Linux is not very good (compared to the Mac)"), but for now, my only real choices are Netscape 4.7 or Mozilla....
As much as I hate defending Microsoft (and by the way, Windows trolls see plenty of alpha software... it's just called "release version" instead of "alpha"), I have to say this:
Microsoft's Mac version of IE 4.0 was a complete rewrite from scratch, and it was slick as hell and far more stable than any Mac version of Netscape or Mozilla (or the previous versions of IE for the Mac, of course).
Also, Opera and iCab were brand new browsers, written from scratch, and their pre-release versions were pretty solid.
The problem here isn't that it's a total rewrite, it's that it's an incredibly ambitious rewrite. Maybe it would have been better to release a 5.0 based on the pre-Gecko engine just to get something useful out the door so people wouldn't have as much to bitch about?
If IE5.5 really does follow the entire DHTML standard (which I believe they claim it will), people will probably eventually recode their pages to follow the standard. But if it doesn't (and Microsoft doesn't always live up to their prerelease claims...), many web developers won't.
Most people I know who make web pages try them with Netscape 4.7 and IE 4.5 on their Macs, and maybe IE 5.0 on Windows if they have a Windows box lying around. If they work there, that's good enough....
Personally, I try to make sure things look good on every reasonably recent version of IE, Netscape, iCab, and Opera on every platform I can find, and even check to make sure it's at least usable with lynx, but I'm not typical.
Yes, Netscape 6PR1 is a (pre-)beta, and people shouldn't expect too much yet. But compare it to the IE 5.5 beta, or the iCab 1.9 alpha, and it looks very unfinished. (I would comment on M15, but there's no linuxppc version yet....)
The public perception may be unfair (I mean, look at the first IE4 preview release...), but that doesn't mean you can ignore it. When you release a product to the public like this, they're not going to read all the warnings--they're going to download it and try it out. And if they don't like it, they're going to be turned off.
"... you can parody anything and anyone, for free."
Tell that to Negativland. (Or eToy, or <your favorite cause here>.)
That may be the way the law was intended, and written, but it's not always the way it's applied.
Netscape and IE are both based partially on Mosaic. And I always though the name meant something like "kick-ass Godzilla-style version of Mosaic," not "Mosaic killer," but I could be wrong.
And Godzilla isn't a dinosaur, so they're obviously cashing in on the most famous dinosaur around, Barney.
More interesting is the fact that Microsoft started identifying IE as "Mozilla" in the user-agent field (so pages that had Netscape-specific features that were only active with the right user agent would show up spiffy in IE).
I still haven't figured out what "Opera" and "iCab" are supposed to mean. And NetPositive almost sounds like it means something, but then you realize that it doesn't....
If you really want to be accurate, Windows 2000 is missing half the features that NT 5.0 was supposed to have (and that were half-way done in the beta).
And by the way, MacOS X, GNOME, and KDE don't bear much code resemblance to MacOS 7, AnotherLevel, or AfterStep either....
When's the last time you used a 10-year-old laptop?
//gs, but I can't imagine doing it now.
/. will still be useful with an HTML 4.0 browser, and all your old slashboxes will come up. So you can finally get to the latest episode of Sluggy Freelance.
First you'd have to remember how to use GNOME 1.0 or MacOS 9 or Windows 98.
Then you'd spend the rest of the day cursing the 366MHz CPU, the tiny 8GB hard drive and 128MB memory.
The chunky 1024x768 resolution that only works from a narrow angle would really bother you. Plus the old-fashioned keyboard--layouts change in 10 years (if we're even still using flat QWERTY-based key arrays)
And what's the chance the trackball or touchpad or thumb thingy would even work after 10 years of dust collecting? And will people still use such things anyway? I used to be perfectly happy navigating windows with a joystick on an Apple
Then you'd remember that it can't connect to the net without some kind of Ethernet thingy connected to DSL or Cable, whatever those are. After a few hours of futzing around, you'd get it connected, and it would run off to your homepage.
So after it tried to hit an IPv4 nameserver to look up the old-style DNS name slashdot.org, you'd spend the next few hours actually getting it connected to the right place. Where it would try to load the page customized for your old account, which hasn't been used in 8 years.
Of course your browser won't support any HTML 9.0 features, but good old
But come on, will Sluggy still be funny after all those years? Pete's good, but he's no Walt Kelly....
Another reason suspending is useful for desktops: There are times when you need to disconnect the plug.
For example, yesterday, I moved my computer to a new UPS. To do this, I had to power down, unplug the computer, plug into the UPS, power up, and go through the whole boot sequence. If I could just suspend, unplug, plug in, and wake, like a laptop, it would have been more convenient. And it would have meant 2 seconds downtime for my server instead of 2 minutes.
It's not that big of a deal, but it's something.
It's not just that. The problem is, people want more and more complicated software--and as it becomes more and more complicated, it also becomes more unstable, inefficient, etc.
Yes, Windows 2000 is even slower and clumsier than Windows 95. But compare GNOME, KDE, and MacOS 9.0 to AnotherLevel, AfterStep, and MacOS 7.5. In every case, they're much bigger, much slower, and less stable.
So why do we continue to upgrade? TWM came preinstalled with my distribution, and yet I never use it.
Part of it is just the spiffiness issue. As Steve Jobs said in explanation of the glowing buttons in Aqua, "Well, when you've got a gigaflop to play with...." My GNOME desktop looks much better than my first X desktop--and most of the apps I run fit in with it pretty well. Plus, Falco dances along to the music when I play MP3s!
For that matter, I can now play MP3s, even mix two at a time. I can edit huge graphics files with GIMP. I have 4 times the pixels at 4 times the color depth and 20 times the net bandwidth, and everything still works smoothly.
And then there's usability. I could ramble on about how nice it is to be able to browse SMB shares, and drag an MP3 onto an XMMS playlist, but there's a much better indicator. My roommate, who's never used anything other than Win9x and MacOS 8/9 was able to sit down at the computer and figure out Netscape, GnomeICU, GEdit, the file manager, etc. within a few hours, with no help. When I tried to get a former roommate to use linux a couple of years ago, she ran screaming from the room....
So yeah, ESD and GNOME and imwheel and so on are slowing down my computer, but I still use them, and I'm sure a lot of other people do. And they make my extra CPU power useful for more than just compiles and games....
Adding to #1, on MacOS, there are a lot of games that use other parts of GameSprockets without using DrawSprockets. There are a lot of games that use standard QuickDraw drawing, but that I can play with my barely-supported joystick thanks to InputSprockets.
There are also cheesy freeware games that have 1986-style graphics, but have network play, 3D sound, and other spiffy GameSprockets features.
A separate thought: it would ideally be as easy as possible for hardware vendors who'd already written DirectX drivers to write Khronos drivers. The question is, how do you do that? Maybe have a "DirectX emualting" driver shell which can plug into Khronos as a driver, but presents a very DirectX-like driver-side API for the hardware vendor. A driver built this way wouldn't be as good as a native driver... but it'd be better than nothing.
"Several orders of magnitude." Well, that's no big deal. Each order of magnitude is, what, 5 years (log 2 10 * 1.5)? So we're talking about 10-15 years until we have the technology?
The big issue is probably not the hardware; it's the training. You can build a huge, kick-ass neural network, but it'll still take a lot of training to do anything useful. Remember that our brain has connections that were made over decades of life, and millenia of evolution. A neural network connected up from scratch won't have that until you train it.
A capacity of 100GB is cheap. Gathering 100GB of data is not.
It's similar to the big problem with traditional (non-connectionist) AI. Who cares if a computer is as powerful as a human brain, if it doesn't have any useful knowledge. Projects like "CYC" have spent years trying to gather enough "common knowledge" information to make a useful AI, but they're nowhere near done.
OK, that's a good point. Monarchs got to collect the taxes and write the laws, and the system ended up perpetuating monarchy.
But if you look at the long run, what eventually happened in nearly every case is that local feudal lords were able to amass more money than the absolute monarchs, and restructure power for their benefit.
Later, the bourgeousie were able to amass more money than the feudal lords, and restructure power for their benefit.
More recently, corporate wealth has far outstripped individual wealth, and the system is being restructured for their benefit.
So things are always changing. Maybe "the more things change, the more they stay the same" as long as "the masses" aren't the ones with the money and power, but still, having money today doesn't guarantee that you're going to have it tomorrow.
OK, as a PPC bigot (well, an anti-x86 bigot) who owns a PPC linux box and two ancient x86 boxes (a P200 and a 486DX2/66), I'll express some interest. I think the best proposal is this:
Instead of a VM, write a cross-platform x86 linux emulator. All system calls run "native;" all x86 instructions are emulated.
Of course I'd prefer a native PPC app over an emulated x86 app, but I'd prefer an emulated x86 app to nothing at all. In the same way that I'd prefer a native linuxppc port to a Mac app under mol, but I prefer mol to not being able to run those apps at all.
Maybe we could even devise a VM that just happens to map instructions one-to-one to x86 instructions. Would this be significantly slower on an x86 than a native x86 app? How much faster would it be on an x86 than a VM designed from scratch? And how much slower would such a VM be on my PPC than a VM designed from scratch? (Another question: Would apps run better in the Itanium implementation of the VM, or in "native" x86 emulation mode?)
By the way, DEC didn't just do some work--they had a 99% functional x86 emulator that was included in NT 4.0 for Alpha. Most apps than ran under NT 4.0 for x86 ran under the emulator--sometimes even faster than on an equivalent-MHz Intel box (sometimes much slower, as well...).
Interestingly, the programs I remember not working were nearly all Microsoft programs, most of which coincidentally had NT Alpha versions (so you had to buy an extra copy, for more money, if you wanted to run it on both...).
But Microsoft abandoned NT Alpha, and I assume DEC abandoned the x86 emulation layer.
Yeah, sure, most of us PPC linux users can just reboot to MacOS (or run mol). But can't most x86 linux users reboot to whatever came preinstalled on their machine (or run vmware or WINE)?
Plus, there are some PPC linux users that aren't using a PowerMac. And some who don't have MacOS on their machine. And what about Sparc and Alpha and ARM and so on?
This will always be a problem with binary-only releases. A source release can be used with every platform out there (unless it uses x86 assembly code or kernel internels from a specific version or something--as a lot of the video stuff does). A binary release often comes out for only one platform, or only the three official RedHat platforms, or only x86 and PPC, etc.--because those are the only machines the company has.
WINE and WineLib just increase the problem.
I have a few x86 linux boxes around. Even though my PPC box is much faster, sometimes I have to run things on one of the Pentiums. Good thing X works, eh?
MacOS isn't a Microsoft OS, and IE 4.5 or 5.0 clobbers Netscape 4.x in every way--speed, stability, size, standards implementation, flexibility, and features. Plus, Steve Jobs told me to use it. (Actually, I use iCab 1.9 more often than either, as it's the only one that hasn't yet crashed my computer.)
The one area where Netscape beats IE is in platform support. IE runs on only Windows, MacOS, and a few Unixes, and it's wildly different on each platform. Netscape 4.7 runs pretty much the same under LinuxPPC as under MacOS, which is pretty nifty.
So what about Netscape 6.0? Well, it closes the gap in some areas, and goes even farther with its multiple platform support--plus, it's based on open source code. But for MacOS or Windows, IE is still better as an everyday browser. Sorry.
No, no, Win2005 won't be out until 2010. It'll be Win2002 that's released in 2005.
First, if you're fired for refusing to comply with an illegal order, you can sue for wrongful termination. And they know this, so you can just threaten it. Of course you'll want to start looking for a new job, but they're not going to fire you for that, or you can sue for retaliation.
For that matter, once you start looking for a new job, you have lots of options. Put the backdoor in as ordered and then tell everyone about it anonymously. Make the backdoor not work. Go way over schedule in implementing it.
And if you're working as a programmer at a major company, you're making enough money that you ought to be able to just quit and support your family for a few weeks while you look for a new job (and cool off your anger).
As for the one hour--well, if all you care about is money, sure, but if I just had to quit a job over something like that, I'd be looking a little more carefully at my next employer....
"You can't be absolutely complacent, unless you both compile everything on your system from source and review all the source code before compiling."
.ppc.rpm and .deb packages...) and likely some people have looked it over. Whereas with Microsoft's source, you know for sure that nobody outside of Microsoft (and companies that have signed NDAs with Microsoft) has seen the source.
True. And even that doesn't help--unless, of course, you're absolutely perfect and there's no way a bug, backdoor, or easter egg could slip past you.
But you can feel much _more_ secure with open-source software than closed-source, even if you don't study the source, or even compile it yourself. Because you know that other people have compiled it (at the very least, whoever built the
When Microsoft releases something, they know people are going to hammer it and try to crash it, penetrate it, or otherwise make it fail. And their software is probably better than it would have otherwise been for this (scary thought, eh?). But they also know that nobody's going to recompile the source, much less study it. And their software is definitely worse than it could have been for this.
But these _are_ benchmarks. Anything that you can test on multiple machines to compare them is a benchmark. And they can be "faked" in the same was as any benchmark--by improving your hardware, drivers, software, etc. for these particular uses.
However, if this is the kind of thing you do all the time, then it's to your benefit if someone tweaks their hardware to improve it.
Apple, with help from Adobe, has gone out of their way to make often-benchmarked Photoshop tests run faster on their machines. But this same effort also makes my actual work with Photoshop go faster--so I have no complaints.
Unfortunately, the end result of optimizing one task may be that other tasks, like starting up Netscape or scrolling in Word, aren't as fast as they could be. Maybe that doesn't matter to you; maybe it does.
The compilation test is a little more problematic. It's very easy to make a compiler run faster by not making the ultimate compiled code slower, or even less accurate. That's obviously something you wouldn't be happy with.
The only way that'll give you any information is if you actually research all the benchmarks.
Imagine you're comparing, say, the IBM and Motorola next versions of the PowerPC. They both advertise benchmarks where they clobber each other. In Motorola's case, they're using lots of stuff that takes advantage of Altivec; in IBM's, they're using lots of stuff that takes advantage of parallelism with multiple cores. If you go read the benchmarks and what they were designed for, then maybe you have enough information to figure out that for your usage, two chips with Altivec is better for you than a single double-core chip without Altivec, or vice-versa. But you could probably figure that out without even looking at benchmarks....
But what is a non-biased test going to do in a situation like that? How much is the "right" amount of FPU usage for the test? Or 128-bit vector processing? It really depends on what you do.
I don't think you can do better than specific application tests. If I spend most of my time waiting for a certain set of GIMP filters to do their thing, what could possibly be a better test for me than one that exercizes those filters, on the types of images that I most often?
So an ideal test would have to contain a huge variety of application subtests, and hopefully everyone could look at the particular subtests they care about.