8)...MDI can be pager with options to choose which document.
And I've never thought that tabbed interfaces are the greatest idea in the world, either. They don't scale to large numbers of documents, they're *incredibly* annoying if you go to a viewport-based system (a la X with most window managers), and they prevent you from looking at multiple documents at once.
Dockable tabs are an interesting idea -- you can "tab" and untab documents by dragging them around. However, no PC UI that I know of has a standard set of conventions for doing this from the keyboard, which is a serious drawback.
MacOS software conventionally (not by Apple dictate, IIRC -- this is not part of the Human Interface Guidelines) uses a "sideways barber pole", a striped, infinitely moving horizontal progress bar to represent an operation in progress with an unknown time of completion.
I've seen a few tries at this, and of the various sorts, I like the MacOS approach the most.
Wget, when downloading a file from a server with an unknown file size, "bounces" a few characters back and forth across the screen.
The MacOS has its "sideways barber pole".
Windows tends to use animated icons, which I don't much like. They aren't standardized or as immediately recognizable, many of them aren't that obvious, and a lot of the icons are downright ugly -- plus, little objects moving around is kind of distracting.
1) You don't like white all over the desktop. This is a fairly interesting topic, and one that I have strong feelings on.
There is a strong tradition, dating back from the times when we had only monochrome monitors, or maybe video cards with 16 or so colors, to use fully saturated, high value colors. Use #0000FF if you want a blue. Use #FF0000 if you want a red. Use #FFFFFF if you want white. Users set their monitor to where it's comfortable to have white be the background to an entire window and work away.
The problem is that this isn't quite right. I have my monitor's white set to sort of a light gray to deal with this -- way too many UI elements require the use of white. Yet this "caps" the monitor at the white of paper. Want to see a sun on the screen? You can't -- it can't get too bright. Same goes for car headlights, etc. In real life, light reflected from paper isn't the brightest white we look at -- yet we've been accustomed since the days of monochrome monitors to have our screen paper color be "full, 100% white". And so we prevent ourselves from really experiencing the dynamic range that our monitors have to offer.
Furthermore, this is very, very difficult to break away from. #FFFFFF has been used so long in standard UI elements that trying to convince everyone to use, say, #AAAAAA for paper means that people would have to set their monitors to either have old games/software be painfully bright or have their new software look dingy. It may someday be possible by having all windows passed through a realtime brightness/contrast/gamma filter on a per-application basis, but until then, our monitors are not capable of rendering a realistic-looking world.
2) You dislike big photorealistic icons. I again disagree. These are good ideas. At the moment, these big icons aren't that great. However, screen resolutions keep increasing. Take a look at high end laptop screens, steadily moving down in price towards the consumer. Bitmaps (we still haven't quite hit the vector revolution, though GNOME and KDE both support vector icons) will be smaller and smaller on screen -- already, middle-aged people often complain about "tiny" 16x16 Windows toolbar icons that were quite large back in the day. Apple took an approach of using real-time scaled icons with large master bitmaps. That means that as resolutions increase, MacOS programs will keep looking good, hopefully on through the next decade. At some point in that time, MS is going to have a much rockier time convincing Windows developers to move to larger graphics.
Also, you may not like photorealistic graphics, but at long, *long* last, computer users can be assumed to be using 32-bit color. The pain and suffering caused to application developers and end users by the least common denominator graphics system being paletted are long gone -- 16 color icons can finally die.
3) Your third point, that QuickTime and iTunes are not consistent or well-designed, is quite good. Many, many people have complained, and both have earned their places in the Interface Hall of Shame. It's particularly embarrasing that Apple, a major HCI leader at one point, would come up with this unusable, nonstandard crap. This is particularly bad because QuickTime 2 was one of the more impressive Mac UI designs, packing lots of usability into a very small space. QT 3+, OTOH, looked awful and worked worse.
5) I've seen some good suggestions that windows should have an "unavailable" indicator in their title bar if they're working on something that's blocking the UI. I think there is even a standard window manager hint for this under Window Maker, though I could be wrong.
Better, of course, would be the at-first-startling ultra-modelessness of the GIMP. The GIMP UI is almost *never* blocked, and there are no modal dialogs. You can flip to whatever window you want and do whatever. At first, some people feel uncomfortable, like the program is giving them too much freedom, but once you get used to it, you never, ever want to go back.
8) I disagree about MDI being a good idea. It's a hack left over from a UI workaround MS made to avoid the flawed VM in Windows 3.1. People have, unfortunately, gotten used to it. However, if you really want to, you can throw at least Classic MacOS (and presumably OS X) into a systemwide MDI mode where when you open an application from the Finder, the Finder becomes hidden.
if your new custom [widget] is well designed for its specific use, rather than merely cobbled together from generic components then any initial time-wasting will be saved
I disagree. I generally find that custom widgets charm developers, and annoy users.
Lets take a look at existing custom widgets. The big annoying ones are bitmap ones (on Windows, often using the standard button as an underly widget). These look different, add nothing to the application, amake the program bigger (esp. to download), slower, look less professional, and seem to frequently be written by interns or something, judging by the quality of them.
There are custom tab widgets. They usually aren't any better than normal tab widgets, especially the annoying reshuffling multi-row tab widgets.
There are animated widgets. Animated widgets are just plain annoying to a lot of people.
There are dials. Every custom widget library seems like it has to come with a dial widget. Dial widgets are about the most difficult interface to work with on a computer, given your input devices (keyboard, mouse).
A lot of examples of what custom widgets do and how bad they are can be found at the excellent Interface Hall of Shame.
There are a *very* few custom widgets that I've seen over the past few years that I think are honestly good and deserve being adopted. I haven't seen a single Windows widget that I like, and in all my years of poking around at human-computer-interaction, I've seen exactly three widgets on the Mac that were a good idea (all of which were pretty much uniformly adopted by the Mac developer community).
A) The slider. The MacOS never had a slider control. When MS copied the Mac's interface elements, this is one of the things they did right -- added a slider. Traditionally, MacOS developers have used scroll bars to fill in the gap, but a fair number of people have introduced a Windows-style slider.
B) The Mercutio MDEF -- this is a menu widget that supports more complex keybindings. The original Mac menu widget only supported Command-A, not Command-A separate from Command-Shift-A. This has been a fairly useful invention (and the UI was done right -- there was a shift symbol added, not just a capital "A" shown in the menu).
C) Windoids. These are the little palettes that vanish when you switch to other apps. They don't look like standard windows, they disappear on their own, but they're so useful that everyone uses them now.
There are also a few, high-level and very custom widgets that don't really appear to the user as widgets, and make reasonable sense. A calendar widget, or something along the lines of GnomeCanvas.
There are quite good newsreaders for the Mac. I suspect that you can probably run the terminal-based newsreaders a la BSD. I use pan on Linux, but I never had a problem with YA-NewsWatcher on the Mac (which evidently has become Thoth).
While I'm sure this will look like anti-MS propoganda, there are certain points to be made here. I have strong negative feelings about the quality of MS's security approach in (1) minimizing local break-in damage, (2) keeping software from having holes, (3) keeping software from being attacked, and (4) vendor bug response approach.
MINIMIZING BREAK-IN DAMAGE
Yes
Yes, services on Windows *can* run as all different users, a la UNIX -- I have ftp, pdnsd, apache, junkbust, squid, xfs, postfix, and sshd set up on my Linux box by default. However, in Windows, *usually*, and *by default* they don't.
Dunno whether Apache for Windows is set up as its own user by default, but most services for Windows don't take advantage of this. You could say that this isn't MS's fault, that there's just less of a multi-user culture around Windows than UNIX, but the fact is that Windows boxes are generally more vulnerable to full compromise in a break-in.
Second, Windows has no concept of "chroot". If I lock something in a chroot jail on UNIX, a hole in a server means next to nothing to me. You broke the server? The files served by the server had better be valuable in and of themself, since you can't get at or see anything else. This doesn't affect most out-of-box distros, since most distros don't go to the trouble of using chroot -- but sites that really value security do use chroot. On Windows, there is no such available option.
Basically, UNIX has a better ability to sandbox, and its capabilities are much more widely used than on Windows -- your average server software developer takes advantage of them on UNIX -- but not on Windows.
KEEPING APPLICATIONS FROM BEING BUGGY
This is a Windows-specific pathname issue. There have been more Windows-specific pathname exploits in Windows servers than I can count. The MS approach of having an extremely convoluted pathname system (particularly files having non-unique names with the backwards compatible 8.3 support) has led to many, many issues with servers. IIS has had numerous holes involving this, and it seems like just about every Windows FTP or Web server has suffered from this at one point or another.
Next, people often complain that UNIX doesn't have ACLs, whereas Windows does. ACLs seem really attractive -- a very easy way to do security work. The problem is that they are much more complicated, and orders of magnitude harder to audit for holes, than the minimalist UNIX security model. Most break-ins are not due to someone literally not having fine-grained enough security -- they're almost always the fault of misconfiguration, which a simpler security model makes massive improvements in. If anyone's every admined a VMS box, you know what I'm talking about -- trying to assure that your box has *no* routes for someone to gain control of the box can be interesting, despite VMS's very fine-grained security model.
Out of box Windows file and registry permissions still hurt the security of Windows boxes -- they aren't as insanely bad as in NT 4.0 out of box any more, but most application vendors are still living in a 9x world, and are focused on adding features, not on maintaining the security model.
Too many Windows subsystems break the Windows security model. I wouldn't trust DirectX and all the non-core stuff on Windows not to have holes -- any yet they post a threat to local security.
As mentioned a while ago in the "shatter attack" article on Slashdot, the windowing model for Windows that worked so well for writing GUI applications easily (well, easily compared to raw Xlib, though Lord knows gtk knocks Win32 into a cocked hat) isn't a very good system from a security standpoint.
KEEPING BUGGY APPLICATIONS FROM BEING ATTACKED
Linux has powerful (granted, not very easy to use, at least without a wrapper) firewalling/routing capabilities through iptables. If your box is ignoring everying from port 22 from outside the computers on your three-person-team at your company, it's rather harder to exploit, say, SSH buffer overflows, or even find a vulnerable server.
Windows has Zone Alarm (and probably other local firewalls, but this is definitely the popular one). Now, this is probably nice for a workstation, but it doesn't compare with iptables in performance, and it doesn't provide the level of control that iptables does. If my internal web server running Apache isn't exposed to people not in my workgroup, then there isn't going to be much exploitation of the server.
MS BUG RESPONSE APPROACH
It's not really all that fair to compare the "46 minute" response time of open-source developers to MS's response time. Yes, in extreme situations someone could get the patch and apply it, in cases of something like the Internet Worm II. Most companies are going to wait for their vendor, be it Red Hat or SuSE or whatever, to come out with a packaged, QAed and supported update. That being said, these fixes still usually come out before MS's fixes. Furthermore, MS eliminates a bunch of their quality guarantees that they provide on Service Packs when you're using HotFixes. Red Hat (at least -- I haven't checked with other vendors) doesn't do that. Their bugfixes are just as fully supported, just as guaranteed to roll back, as their release software. That means that their updates better compare to Service Packs, which take forever and a day to come out after an exploit. So MS usually takes a long time to fix bugs.
Also, MS's primary to-end-user bugfix distribution format is Windows Update. Windows Update is one of the least impressive update systems I've seen yet -- it's used to update system software, yet it relies on a huge amount of application and system software. If it screws up, you're dead. And I've had a number of unpleasant experiences with Windows Update failing one way or another -- for example, once I had a bluescreen on a reboot after updating and trying to run MSIE (keep in mind that this is an NT-line kernel, not 9x). I've seen error dialogs during updates, and other semi-disturbing blemishes. After two incidents where Windows Update rendered boxes unbootable, I've taken to not running Windows Update (even to fix security issues) unless I have a known free two days to reinstall the OS and get everything running wrinkle-free again if something goes hideously wrong.
Furthermore, because of the way Windows does file and DLL locking (stupid, stupid -- ever try moving/deleting/renaming an open file under Windows? Combined with Explorer sometimes leaking file handles, this is a royal PITA), low-level updates usually require a reboot. The only Linux update that requires a reboot is a kernel update (though updating a desktop environment or a WM requires logging out and back in again to see the changes). Finally, I've ripped out much of my RPM-based Linux system and put in back in (bits of different distros, bits of devel-branch software) and always had smooth moves, nothing that could make my system unbootable. I feel a lot more confident in an RPM installation or uninstallation than I do in a Windows update.
Anyway, just my two cents -- just wanted to point out that this issue can still be partly blamed on Windows security issues, and not wanting people to lose sight of the areas in which MS needs to improve.
Actually, I believe you need Ximian Connector, a non-free piece of software (not that I have qualms about buying from Ximian), to use Evolution with Exchange.
If you have it, you get shared calendar and whatnot.
It'd be interesting to try running Mozilla + OpenOffice + Evolution and see what people think (aside from not liking the three different UIs:-) )
I'm not sure. The knowledge or experience may have some intrinsic value -- maybe you learn something.
I'll spend much longer when fixing something figuring out *why* it broke then just "getting it working again and forgetting about it" because in the long term, this pays off. Well, at least I hope so.
I remember this being written somewhere in a book or magazine: "They were software engineers, the sort of people that will spend four hours calculating different trip routes to save ten minutes taking the shortest possible trip".
This may be less true for simple piracy, but if you're actually cracking the software yourself, there's some educational value to the whole process.
* p2p movie sharing. Heck, keep your movie archive online. * programs with support for unlimited undo, where a complete history of actions is stored (if someone beats MS Office to market with this and people get used to it, there will be a nice coup. * Large http cache * use flac instead of mp3 for lossless audio. No more worries about compression artifacts. * Use png instead of jpg for images (granted, there are probably better lossless photo compression algorithms, but png is quite common). No more worries about compression artifacts. * Copy CD images onto your hard drive and either loopback mount them in Linux or use Daemon Tools in Windows -- no more searching for a CD, and load times are much better. * Instead of bookmarking web sites you like, use a tool to download them -- you never know when they'll vanish forever. * Don't uninstall software to save space (a big issue with games on Windows) * Partition the drive and try out another OS * Try out freenet, with a nice big cache to speed your (and others near you) access time * Send it to me. *My* drive is full.:-)
When you have fair use for education rights, that's along the lines of being able to use material as examples of material in a field. You can't say "I'm associated with an educational institution, and therefore I'm immune from all copyright issues" -- heck, if you could, a lot of people would just be pirating Photoshop right about now.
MIT should pay something -- at the very least, they'd have to pay the equivalent of an artist's commission to get the work done, and I really think that swiping an artist's or author's work should incur penal damages, given how hard it is to pick up on and how tough it can make things for artists.
OTOH, if they're shooting for millions of dollars, I think they should go back to making comics.
Finally, the people involved should be penalized. They did something wrong, and were caught doing it.
Nobody said anything about emulation. A port is a native compilation, and therefore no performance hit is taken.
This is a quarter-truth. However, you're ignoring a fair number of issues:
* A port would likely be less tweaked for the architecture (run out of registers more likely, cause cache misses, whatever) for some time.
* Apple didn't port all of the MacOS to the PPC for *ages* (actually, I'm not sure the entire OS ever went native). They just ported critical chunks, and emulated less used bits. If you want to avoid emulation, you're looking at a much larger porting task in a short period of the time.
* Apple could port the OS -- but 99% of applications won't be recompiled for the x86. That means a lot of apps need to be emulated.
Furthermore, your assumption that PPC is automagically more powerful than Intel architectures is a clear indication that you are severiously under-informed.
Actually, he's right, though he simplified things a bit. The PPC has far more registers than the x86 architecture. Any emulation would involve extremely expensive swapping of registers very frequently. I'm don't remember what L1 fetch time on the x86 is, but it's at least one cycle. That means that your PPC code is going to run, at best, at half speed a fair bit of the time.
The reason the PPC could emulate the 680x0 so efficiently is because it had so many registers and didn't have to execute many instructions to handle any single 680x0 instruction. Also, the PPC was a faster chip, so running slow 680x0 code still seemed reasonably peppy to the user -- trying to port PPC code to the x86, a *competitive* line, means looking at some serious slowdown issues.
I won't go so far as to call you a newbie, but your bias suggests that you have a ways to go before you become a seasoned professional. Keep on plugging though, and try to be more open-minded. Consider doing research before forming conclusions, for example.
I think that you owe it to the parent poster to do the same yourself.
You know, there are people (like myself) who don't approve of ICANN's decisions but *still* think that unlimited TLDs are an awful idea.
Frankly, I don't think even the new TLDs should have been allowed. The problem is not, and never was, a limited name space. It was "keyword space" in the.com area, domain name squatting, and companies buying related names.
The "keyword space" issue was Netscape's fault. However, *both* of the others were problems caused by registrars encouraging people to squat on domains and companies to "also buy the related.org and.net addresses with one easy click!".
Also, while I like the *idea* of OpenNIC (an alternative group of people doing things the "right" way), I've been less than impressed with the reality. OpenNIC seems to mostly devolve into political/ideological arguments reminicent of the HURD or Debian mailing lists, rather than to be terribly effective. Finally, my idea of the "right way" is to not add in bogus TLDs like ".biz" and friends.
So I'd almost call this post a troll, but it has a point -- that maybe commercial types would do a better job.
However, you're missing one thing -- the informal group of volunteers and engineers that produced and have kept much of the administrative side of the Internet going for thirty years now *are* the open source/volunteer types that you're bashing so much. As a matter of fact, the commercial types are the untested ones, not the volunteer engineers.
I dunno. So far, in the quest for "world domination", Open Source is behind but coming up fast.
Plus, MS and Open Source are both looking for certain threshhold percentage user levels taht they need to become extremely powerful. If MS has about 90% user base in a market, they can wield monopoly powers, which they've used with great success in the past. The GPL also needs a certain threshhold, to the point where it becomes a major drawback *not* to use the GPL. At that point, more people start joining, which furthers the effect, producing a landslide. And the GPL required threshhold is much, much lower -- I'd estimate that if 10% of the users out there are using GPL software that Microsoft doesn't really have a prayer.
Oops -- it was not, in fact, MS. I had been skimming something a long time ago that was talking about it, referring to MS's header files. It turns out that there was actually a different case that set precedent, and that this was then mentioned in reference to Microsoft.
I'm not sure what the original document was where I read this, but it's also talked about a bit in this recent WINE->GPL thread.
The crucial sentence in the court's decision:"When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement".
Now, before Slashdot people start going ape all over this ("But this is the *only* way to compress MP3/compress GIF files so we should be able to do it"), keep in mind that this refers *only* to copyright, not patent law.
Interestingly enough, this passage may give carte blanche to MS to steal whatever chunks of machine code from AOL Instant Messanger they want to to allow interoperability between MSN Messenger and AIM. The same goes for cryptographic signatures containing copyrighted information (*cough* X-Box), and whatnot.
Slashdot Mirror
8)...MDI can be pager with options to choose which document.
And I've never thought that tabbed interfaces are the greatest idea in the world, either. They don't scale to large numbers of documents, they're *incredibly* annoying if you go to a viewport-based system (a la X with most window managers), and they prevent you from looking at multiple documents at once.
Dockable tabs are an interesting idea -- you can "tab" and untab documents by dragging them around. However, no PC UI that I know of has a standard set of conventions for doing this from the keyboard, which is a serious drawback.
5) No happenings.
MacOS software conventionally (not by Apple dictate, IIRC -- this is not part of the Human Interface Guidelines) uses a "sideways barber pole", a striped, infinitely moving horizontal progress bar to represent an operation in progress with an unknown time of completion.
I've seen a few tries at this, and of the various sorts, I like the MacOS approach the most.
Wget, when downloading a file from a server with an unknown file size, "bounces" a few characters back and forth across the screen.
The MacOS has its "sideways barber pole".
Windows tends to use animated icons, which I don't much like. They aren't standardized or as immediately recognizable, many of them aren't that obvious, and a lot of the icons are downright ugly -- plus, little objects moving around is kind of distracting.
1) You don't like white all over the desktop. This is a fairly interesting topic, and one that I have strong feelings on.
There is a strong tradition, dating back from the times when we had only monochrome monitors, or maybe video cards with 16 or so colors, to use fully saturated, high value colors. Use #0000FF if you want a blue. Use #FF0000 if you want a red. Use #FFFFFF if you want white. Users set their monitor to where it's comfortable to have white be the background to an entire window and work away.
The problem is that this isn't quite right. I have my monitor's white set to sort of a light gray to deal with this -- way too many UI elements require the use of white. Yet this "caps" the monitor at the white of paper. Want to see a sun on the screen? You can't -- it can't get too bright. Same goes for car headlights, etc. In real life, light reflected from paper isn't the brightest white we look at -- yet we've been accustomed since the days of monochrome monitors to have our screen paper color be "full, 100% white". And so we prevent ourselves from really experiencing the dynamic range that our monitors have to offer.
Furthermore, this is very, very difficult to break away from. #FFFFFF has been used so long in standard UI elements that trying to convince everyone to use, say, #AAAAAA for paper means that people would have to set their monitors to either have old games/software be painfully bright or have their new software look dingy. It may someday be possible by having all windows passed through a realtime brightness/contrast/gamma filter on a per-application basis, but until then, our monitors are not capable of rendering a realistic-looking world.
2) You dislike big photorealistic icons. I again disagree. These are good ideas. At the moment, these big icons aren't that great. However, screen resolutions keep increasing. Take a look at high end laptop screens, steadily moving down in price towards the consumer. Bitmaps (we still haven't quite hit the vector revolution, though GNOME and KDE both support vector icons) will be smaller and smaller on screen -- already, middle-aged people often complain about "tiny" 16x16 Windows toolbar icons that were quite large back in the day. Apple took an approach of using real-time scaled icons with large master bitmaps. That means that as resolutions increase, MacOS programs will keep looking good, hopefully on through the next decade. At some point in that time, MS is going to have a much rockier time convincing Windows developers to move to larger graphics.
Also, you may not like photorealistic graphics, but at long, *long* last, computer users can be assumed to be using 32-bit color. The pain and suffering caused to application developers and end users by the least common denominator graphics system being paletted are long gone -- 16 color icons can finally die.
3) Your third point, that QuickTime and iTunes are not consistent or well-designed, is quite good. Many, many people have complained, and both have earned their places in the Interface Hall of Shame. It's particularly embarrasing that Apple, a major HCI leader at one point, would come up with this unusable, nonstandard crap. This is particularly bad because QuickTime 2 was one of the more impressive Mac UI designs, packing lots of usability into a very small space. QT 3+, OTOH, looked awful and worked worse.
5) I've seen some good suggestions that windows should have an "unavailable" indicator in their title bar if they're working on something that's blocking the UI. I think there is even a standard window manager hint for this under Window Maker, though I could be wrong.
Better, of course, would be the at-first-startling ultra-modelessness of the GIMP. The GIMP UI is almost *never* blocked, and there are no modal dialogs. You can flip to whatever window you want and do whatever. At first, some people feel uncomfortable, like the program is giving them too much freedom, but once you get used to it, you never, ever want to go back.
8) I disagree about MDI being a good idea. It's a hack left over from a UI workaround MS made to avoid the flawed VM in Windows 3.1. People have, unfortunately, gotten used to it. However, if you really want to, you can throw at least Classic MacOS (and presumably OS X) into a systemwide MDI mode where when you open an application from the Finder, the Finder becomes hidden.
if your new custom [widget] is well designed for its specific use, rather than merely cobbled together from generic components then any initial time-wasting will be saved
I disagree. I generally find that custom widgets charm developers, and annoy users.
Lets take a look at existing custom widgets. The big annoying ones are bitmap ones (on Windows, often using the standard button as an underly widget). These look different, add nothing to the application, amake the program bigger (esp. to download), slower, look less professional, and seem to frequently be written by interns or something, judging by the quality of them.
There are custom tab widgets. They usually aren't any better than normal tab widgets, especially the annoying reshuffling multi-row tab widgets.
There are animated widgets. Animated widgets are just plain annoying to a lot of people.
There are dials. Every custom widget library seems like it has to come with a dial widget. Dial widgets are about the most difficult interface to work with on a computer, given your input devices (keyboard, mouse).
A lot of examples of what custom widgets do and how bad they are can be found at the excellent Interface Hall of Shame.
There are a *very* few custom widgets that I've seen over the past few years that I think are honestly good and deserve being adopted. I haven't seen a single Windows widget that I like, and in all my years of poking around at human-computer-interaction, I've seen exactly three widgets on the Mac that were a good idea (all of which were pretty much uniformly adopted by the Mac developer community).
A) The slider. The MacOS never had a slider control. When MS copied the Mac's interface elements, this is one of the things they did right -- added a slider. Traditionally, MacOS developers have used scroll bars to fill in the gap, but a fair number of people have introduced a Windows-style slider.
B) The Mercutio MDEF -- this is a menu widget that supports more complex keybindings. The original Mac menu widget only supported Command-A, not Command-A separate from Command-Shift-A. This has been a fairly useful invention (and the UI was done right -- there was a shift symbol added, not just a capital "A" shown in the menu).
C) Windoids. These are the little palettes that vanish when you switch to other apps. They don't look like standard windows, they disappear on their own, but they're so useful that everyone uses them now.
There are also a few, high-level and very custom widgets that don't really appear to the user as widgets, and make reasonable sense. A calendar widget, or something along the lines of GnomeCanvas.
There are quite good newsreaders for the Mac. I suspect that you can probably run the terminal-based newsreaders a la BSD. I use pan on Linux, but I never had a problem with YA-NewsWatcher on the Mac (which evidently has become Thoth).
Take a look here for other newsreaders.
And now China will block that alltooflat mirror site.
And you wanna bet that posting suggestions on how to beat their firewall is gonna get Slashdot blocked?
Ah, well. The whole China censorship thing is one of the few areas where Voice of America isn't full of crap -- it's pretty egregious.
While I'm sure this will look like anti-MS propoganda, there are certain points to be made here. I have strong negative feelings about the quality of MS's security approach in (1) minimizing local break-in damage, (2) keeping software from having holes, (3) keeping software from being attacked, and (4) vendor bug response approach.
MINIMIZING BREAK-IN DAMAGE
Yes
Yes, services on Windows *can* run as all different users, a la UNIX -- I have ftp, pdnsd, apache, junkbust, squid, xfs, postfix, and sshd set up on my Linux box by default. However, in Windows, *usually*, and *by default* they don't.
Dunno whether Apache for Windows is set up as its own user by default, but most services for Windows don't take advantage of this. You could say that this isn't MS's fault, that there's just less of a multi-user culture around Windows than UNIX, but the fact is that Windows boxes are generally more vulnerable to full compromise in a break-in.
Second, Windows has no concept of "chroot". If I lock something in a chroot jail on UNIX, a hole in a server means next to nothing to me. You broke the server? The files served by the server had better be valuable in and of themself, since you can't get at or see anything else. This doesn't affect most out-of-box distros, since most distros don't go to the trouble of using chroot -- but sites that really value security do use chroot. On Windows, there is no such available option.
Basically, UNIX has a better ability to sandbox, and its capabilities are much more widely used than on Windows -- your average server software developer takes advantage of them on UNIX -- but not on Windows.
KEEPING APPLICATIONS FROM BEING BUGGY
This is a Windows-specific pathname issue. There have been more Windows-specific pathname exploits in Windows servers than I can count. The MS approach of having an extremely convoluted pathname system (particularly files having non-unique names with the backwards compatible 8.3 support) has led to many, many issues with servers. IIS has had numerous holes involving this, and it seems like just about every Windows FTP or Web server has suffered from this at one point or another.
Next, people often complain that UNIX doesn't have ACLs, whereas Windows does. ACLs seem really attractive -- a very easy way to do security work. The problem is that they are much more complicated, and orders of magnitude harder to audit for holes, than the minimalist UNIX security model. Most break-ins are not due to someone literally not having fine-grained enough security -- they're almost always the fault of misconfiguration, which a simpler security model makes massive improvements in. If anyone's every admined a VMS box, you know what I'm talking about -- trying to assure that your box has *no* routes for someone to gain control of the box can be interesting, despite VMS's very fine-grained security model.
Out of box Windows file and registry permissions still hurt the security of Windows boxes -- they aren't as insanely bad as in NT 4.0 out of box any more, but most application vendors are still living in a 9x world, and are focused on adding features, not on maintaining the security model.
Too many Windows subsystems break the Windows security model. I wouldn't trust DirectX and all the non-core stuff on Windows not to have holes -- any yet they post a threat to local security.
As mentioned a while ago in the "shatter attack" article on Slashdot, the windowing model for Windows that worked so well for writing GUI applications easily (well, easily compared to raw Xlib, though Lord knows gtk knocks Win32 into a cocked hat) isn't a very good system from a security standpoint.
KEEPING BUGGY APPLICATIONS FROM BEING ATTACKED
Linux has powerful (granted, not very easy to use, at least without a wrapper) firewalling/routing capabilities through iptables. If your box is ignoring everying from port 22 from outside the computers on your three-person-team at your company, it's rather harder to exploit, say, SSH buffer overflows, or even find a vulnerable server.
Windows has Zone Alarm (and probably other local firewalls, but this is definitely the popular one). Now, this is probably nice for a workstation, but it doesn't compare with iptables in performance, and it doesn't provide the level of control that iptables does. If my internal web server running Apache isn't exposed to people not in my workgroup, then there isn't going to be much exploitation of the server.
MS BUG RESPONSE APPROACH
It's not really all that fair to compare the "46 minute" response time of open-source developers to MS's response time. Yes, in extreme situations someone could get the patch and apply it, in cases of something like the Internet Worm II. Most companies are going to wait for their vendor, be it Red Hat or SuSE or whatever, to come out with a packaged, QAed and supported update. That being said, these fixes still usually come out before MS's fixes. Furthermore, MS eliminates a bunch of their quality guarantees that they provide on Service Packs when you're using HotFixes. Red Hat (at least -- I haven't checked with other vendors) doesn't do that. Their bugfixes are just as fully supported, just as guaranteed to roll back, as their release software. That means that their updates better compare to Service Packs, which take forever and a day to come out after an exploit. So MS usually takes a long time to fix bugs.
Also, MS's primary to-end-user bugfix distribution format is Windows Update. Windows Update is one of the least impressive update systems I've seen yet -- it's used to update system software, yet it relies on a huge amount of application and system software. If it screws up, you're dead. And I've had a number of unpleasant experiences with Windows Update failing one way or another -- for example, once I had a bluescreen on a reboot after updating and trying to run MSIE (keep in mind that this is an NT-line kernel, not 9x). I've seen error dialogs during updates, and other semi-disturbing blemishes. After two incidents where Windows Update rendered boxes unbootable, I've taken to not running Windows Update (even to fix security issues) unless I have a known free two days to reinstall the OS and get everything running wrinkle-free again if something goes hideously wrong.
Furthermore, because of the way Windows does file and DLL locking (stupid, stupid -- ever try moving/deleting/renaming an open file under Windows? Combined with Explorer sometimes leaking file handles, this is a royal PITA), low-level updates usually require a reboot. The only Linux update that requires a reboot is a kernel update (though updating a desktop environment or a WM requires logging out and back in again to see the changes). Finally, I've ripped out much of my RPM-based Linux system and put in back in (bits of different distros, bits of devel-branch software) and always had smooth moves, nothing that could make my system unbootable. I feel a lot more confident in an RPM installation or uninstallation than I do in a Windows update.
Anyway, just my two cents -- just wanted to point out that this issue can still be partly blamed on Windows security issues, and not wanting people to lose sight of the areas in which MS needs to improve.
One assembles assembly with an assembler.
You don't code in "assembler" language, you code in "assembly" language.
Actually, I believe you need Ximian Connector, a non-free piece of software (not that I have qualms about buying from Ximian), to use Evolution with Exchange.
:-) )
If you have it, you get shared calendar and whatnot.
It'd be interesting to try running Mozilla + OpenOffice + Evolution and see what people think (aside from not liking the three different UIs
I'm not sure. The knowledge or experience may have some intrinsic value -- maybe you learn something.
I'll spend much longer when fixing something figuring out *why* it broke then just "getting it working again and forgetting about it" because in the long term, this pays off. Well, at least I hope so.
I remember this being written somewhere in a book or magazine: "They were software engineers, the sort of people that will spend four hours calculating different trip routes to save ten minutes taking the shortest possible trip".
This may be less true for simple piracy, but if you're actually cracking the software yourself, there's some educational value to the whole process.
I don't think Ellison has a beef with the *AA.
He's a Microsoft enemy, yes...
Hmmm....here are some suggestions.
:-)
* p2p movie sharing. Heck, keep your movie archive online.
* programs with support for unlimited undo, where a complete history of actions is stored (if someone beats MS Office to market with this and people get used to it, there will be a nice coup.
* Large http cache
* use flac instead of mp3 for lossless audio. No more worries about compression artifacts.
* Use png instead of jpg for images (granted, there are probably better lossless photo compression algorithms, but png is quite common). No more worries about compression artifacts.
* Copy CD images onto your hard drive and either loopback mount them in Linux or use Daemon Tools in Windows -- no more searching for a CD, and load times are much better.
* Instead of bookmarking web sites you like, use a tool to download them -- you never know when they'll vanish forever.
* Don't uninstall software to save space (a big issue with games on Windows)
* Partition the drive and try out another OS
* Try out freenet, with a nice big cache to speed your (and others near you) access time
* Send it to me. *My* drive is full.
I rather think that the similarity was the point. What, you don't find it funny?
I mean, that's a rather effective use of irony...
What happens the first time someone registers billyg@microsoft.com
Well, his signed messages won't match up an he won't be able to decrypt anything from the PGP pubkey, which you *should* be using...
More than three people use MS Messenger?
How does MIT have a case to be made for fair use?
When you have fair use for education rights, that's along the lines of being able to use material as examples of material in a field. You can't say "I'm associated with an educational institution, and therefore I'm immune from all copyright issues" -- heck, if you could, a lot of people would just be pirating Photoshop right about now.
MIT should pay something -- at the very least, they'd have to pay the equivalent of an artist's commission to get the work done, and I really think that swiping an artist's or author's work should incur penal damages, given how hard it is to pick up on and how tough it can make things for artists.
OTOH, if they're shooting for millions of dollars, I think they should go back to making comics.
Finally, the people involved should be penalized. They did something wrong, and were caught doing it.
Nobody said anything about emulation. A port is a native compilation, and therefore no performance hit is taken.
This is a quarter-truth. However, you're ignoring a fair number of issues:
* A port would likely be less tweaked for the architecture (run out of registers more likely, cause cache misses, whatever) for some time.
* Apple didn't port all of the MacOS to the PPC for *ages* (actually, I'm not sure the entire OS ever went native). They just ported critical chunks, and emulated less used bits. If you want to avoid emulation, you're looking at a much larger porting task in a short period of the time.
* Apple could port the OS -- but 99% of applications won't be recompiled for the x86. That means a lot of apps need to be emulated.
Furthermore, your assumption that PPC is automagically more powerful than Intel architectures is a clear indication that you are severiously under-informed.
Actually, he's right, though he simplified things a bit. The PPC has far more registers than the x86 architecture. Any emulation would involve extremely expensive swapping of registers very frequently. I'm don't remember what L1 fetch time on the x86 is, but it's at least one cycle. That means that your PPC code is going to run, at best, at half speed a fair bit of the time.
The reason the PPC could emulate the 680x0 so efficiently is because it had so many registers and didn't have to execute many instructions to handle any single 680x0 instruction. Also, the PPC was a faster chip, so running slow 680x0 code still seemed reasonably peppy to the user -- trying to port PPC code to the x86, a *competitive* line, means looking at some serious slowdown issues.
I won't go so far as to call you a newbie, but your bias suggests that you have a ways to go before you become a seasoned professional. Keep on plugging though, and try to be more open-minded. Consider doing research before forming conclusions, for example.
I think that you owe it to the parent poster to do the same yourself.
I personally find there to be a great deal of value in being able to look up the geographical location that a name corresponds to.
I find your claim that only the "half educated few in between" want limited TLDs to be insulting.
You know, there are people (like myself) who don't approve of ICANN's decisions but *still* think that unlimited TLDs are an awful idea.
.com area, domain name squatting, and companies buying related names.
.org and .net addresses with one easy click!".
Frankly, I don't think even the new TLDs should have been allowed. The problem is not, and never was, a limited name space. It was "keyword space" in the
The "keyword space" issue was Netscape's fault. However, *both* of the others were problems caused by registrars encouraging people to squat on domains and companies to "also buy the related
Also, while I like the *idea* of OpenNIC (an alternative group of people doing things the "right" way), I've been less than impressed with the reality. OpenNIC seems to mostly devolve into political/ideological arguments reminicent of the HURD or Debian mailing lists, rather than to be terribly effective. Finally, my idea of the "right way" is to not add in bogus TLDs like ".biz" and friends.
So I'd almost call this post a troll, but it has a point -- that maybe commercial types would do a better job.
However, you're missing one thing -- the informal group of volunteers and engineers that produced and have kept much of the administrative side of the Internet going for thirty years now *are* the open source/volunteer types that you're bashing so much. As a matter of fact, the commercial types are the untested ones, not the volunteer engineers.
I have a little Radio Shack kit as recommended above, which I endorse. Here's my breakdown:
Phillips and flathead screwdrivers, in two sizes each (you need a dinky little pair for some screws).
Tweezers (these can get awfully useful)
Two hex drivers in different sizes (so you don't strip case screws...I love hex drivers).
Torx screwdriver with two sizes of head that doubles as a large hex driver.
Pair of tweezers.
Little gitchie-grabber thingie to grasp tiny parts where your fingers can't fit.
Case to store extra screws and screws in use. Losing screws from the case you're working on can get really, really easy.
The non-useful bits that came with the kit: IC removers. Why the *hell* do they ship IC removers with repair kits any more?
I added the following to the kit:
Pair of forceps. Holding wires or little bits out of the way can come in handy. Fishing/bait kits have these.
Needlenose pliers. Useful for all sorts of stuff. I strongly recommend these.
and Microsoft's lackey, Apple
Err...yeah. Apple and Microsoft just love each other.
They aren't trying to beat each other to death, mostly because for MS it isn't worth the effort, and because for Apple it isn't feasible.
I dunno. So far, in the quest for "world domination", Open Source is behind but coming up fast.
Plus, MS and Open Source are both looking for certain threshhold percentage user levels taht they need to become extremely powerful. If MS has about 90% user base in a market, they can wield monopoly powers, which they've used with great success in the past. The GPL also needs a certain threshhold, to the point where it becomes a major drawback *not* to use the GPL. At that point, more people start joining, which furthers the effect, producing a landslide. And the GPL required threshhold is much, much lower -- I'd estimate that if 10% of the users out there are using GPL software that Microsoft doesn't really have a prayer.
Oops -- it was not, in fact, MS. I had been skimming something a long time ago that was talking about it, referring to MS's header files. It turns out that there was actually a different case that set precedent, and that this was then mentioned in reference to Microsoft.
I'm not sure what the original document was where I read this, but it's also talked about a bit in this recent WINE->GPL thread.
The crucial sentence in the court's decision:"When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement".
Now, before Slashdot people start going ape all over this ("But this is the *only* way to compress MP3/compress GIF files so we should be able to do it"), keep in mind that this refers *only* to copyright, not patent law.
Interestingly enough, this passage may give carte blanche to MS to steal whatever chunks of machine code from AOL Instant Messanger they want to to allow interoperability between MSN Messenger and AIM. The same goes for cryptographic signatures containing copyrighted information (*cough* X-Box), and whatnot.