That would be a trip. Remember, dupe is short for duplicate. The correct abbreviation for three stories would be "trip", which is short for "triplicate" (which is a real word, yes).
The real question is why I'm debating the correct abbreviations for Slashdot editorial errors on Slashdot...
Ease of entering non-Western text. OS X is the only operating system I've gotten to easily and effortlessly switch between QWERTY/Dvorak, Japanese, Chinese, and Korean. If I could use it, I could also use about fifty billion other language input methods, including various eastern European languages, Hindi, Arabic, Hebrew, and Thai. The only way I have any idea how you'd do that under Linux/X11 is to multiplex X Input Methods, and I don't know of any applications that do that.
Besides that, Darwin's I/O systems probably aren't as bad as you've heard, speaking from experience. I do lament the lack of virtual desktops, and I'm running 10.2, so I don't have Exposé. OS X really isn't that bad of a system - which is a good thing, as I'm stuck with it for a bit, since my PC just died. (This post is written on my iBook.)
I also have to comment on multilingual support on OS X here, because it's just that good.
Non-western text is supported throughout the operating system transparently. Switching input languages is as simple as pressing Cmd-Space. (You can also use the language menu at the top of the screen, which is similar to the language panel in the Windows taskbar. If you don't want to be able to use Cmd-Space, you can turn that off, but I've never accidentally hit it.) Just go to the International panel in System Preferences and select what languages you want to add to the language menu.
The system uses UTF-8 universally, not UCS-16 like under Windows. I'm not sure if you can use "legacy" character sets, so if Han unification is an issue for you, you'd need to figure out how to deal with that. (I'd bet someone's already had to.)
I absolutely love the Japanese input method. Kanji lookup works quite well, and "adapts" to remember which kana->kanji conversions you use most often. it's pretty much what you'd expect; type kana, hit space, select from the menu that pops up. You can navigate the menu using the keyboard or the mouse. Mac OS X makes Japanese input easy. (I've also had opportunity to try the Traditional Chinese input, it's basically just as good. Korean always screws me up, though, just because I'm not very familiar with the standard Korean romanization systems.)
Oh, and if you don't know a kanji's pronunciation, the Character Palette (kind of like Character Map in Windows, but not at all) lists kanji by radical, sorted by stroke order. You can also get easy access to various symbols (circled katakana, kanji numerals, and stuff like stars from the JIS tables) by looking in the "by Category" tab in the Japanese view. There's also listing by code tables, if you happen to know JIS or Shift JIS codes.
Similar facilities exist in other operating systems (excepting, I'd say, the Character Palette), but I've never had as good experiences with i18n as I have in OS X.
... but you don't need AMD64 for basic desktop tasks. Remember, poster said "... which would actually probably be more to the liking of the average PC user - who just checks their email and surfs the web."
Granted, I'm speccing dual G5 and dual AMD64 systems as possibilities for the next desktop I buy - but I want it to last at least a decade, and have it serve as a desktop system while I'm doing development and content creation at the same time. Most people don't need that sort of power - hell, I'd be perfectly happy with my 866 MHz Pentium 3 based system if the hardware wasn't going.
... so you're telling me that testing and QA are equally worthless on modern processors like the (massively complex) Itanium family? They may not perform as well as expected - that's due to incorrect assumptions about things like compiler quality and actual effectiveness of features like predication - but when's the last time you heard of Itanium chips being recalled because they didn't run code correctly? I doubt one would argue that Itanium implementations, with their 220 million transistors and "more lines on them than a London road map", are somehow trivial compared to a modern software application. If QA can work for complex things like hard drives, aerospace vehicles, and modern microprocessors, I'm guessing there's a way to successfully apply it to the software industry.
I've seen it said that testing is not the exact same thing as quality assurance. I don't know what else people associate with QA, but you may want to consider that possibility.
Certain processor designs can be better suited to different tasks. For example, there was a point when the Alpha beat the shit out of Intel's offerings in integer performance in part because of a significant clock speed gap, but had rather superior floating point performance, even if you extrapolated Intel's performance up to match the Alpha's clock rate. (Aside from issues like performance not scaling perfectly with clock rate, which you should learn about early this semester if this is a real computer architecture class:3 ) Different processors designs can be strong or weak in much different areas.
GPUs aren't meant to be general purpose processors. They're good at doing the sort of calculations that you need to do rotations, shading, and other pretty graphical things, and suck at pretty much everything else. (My unresearched understanding is that this is because GPUs tend to be optimized for floating point performance.) For reasons like this, you probably won't be seeing any add-ons to let you do word processing on your video card while you surf the web any time soon.
Really? I alternately use GNU/Linux on x86 hardware (currently dead, but it was my main machine) and an iBook. The PC, of course, has a "three button" (two buttons and a scroll wheel) optical mouse. The iBook, obviously, has a one-button trackpad. I could easily plug the mouse into the iBook, but I never really need to. I guess I'm not metal enough to turn dumb when I sit behind a Mac:3
You're falling into one of the most common "usability" traps - thinking that what is best for you is best for everyone, or at least, talking in a manner that implies you think that way. I think it's a pity how many armchair usability expert discussions degenerate into "THIS IS THE ONE TRUE WAY GODS DAMMIT"...
I would suggest re-naming "rmbdd()". I _assume_ that "dd" stands for "data dependent", but quite frankly, "rmbdd" looks like the standard IBM "we lost every vowel ever invented" kind of assembly lanaguage to me.
I'm sure that having programmed PPC assembly language, you find it very natural (IBM motto: "We found five vowels hiding in a corner, and we used them _all_ for the 'eieio' instruction so that we wouldn't have to use them anywhere else").
Alpha's main wins over Intel architectures at the time were clock speed (DEC hit 500 MHz rather before Intel did, I believe) and floating point performance. Of course, a lot of architectures have better floating point performance than Intel's 32-bit stuff... though this is less true with the advent of SSE.
Pff, it's not that clear cut, as most people know.
Much of the lower level workings of "IA-32" chips are a lot more RISCy than they started out being. More complex instructions are implemented in microcode. On the flip side, architectures like PowerPC (and even SPARC... register windows are neat, but not very RISC) aren't very RISCy at all compared with stuff like MIPS.
Neither side won absolutely. This is probably as it should be.
You had me willing to try zsh for my next system's default shell until you mentioned multibyte support. Oh, the utter pain in the ass I've gone through with UTF-8 at times...
Re:bash = "embrace and extend" proprietary crap
on
Bash 3.0 Released
·
· Score: 1
Your problem is with a load of stupid fucking script-wanking morons who can't read SuS specs, not with bash.
I don't know if the Rijndael cipher (the algorithm that one the AES contest, essentially) is covered by any patents, but it doesn't matter - the winner agrees to allow anyone to use the cipher regardless of patent coverage, essentially.
RC5, however, does use techniques covered by patents. You'll find that some GNU/Linux distributions, such as Red Hat, don't even include the OpenSSL support for it for that reason. (RH7x also left out IDEA, but unfortunately I don't know about more recent releases.) And I know I've read accounts of people having to build OpenSSL with no-rsa or no-rc5 because RSA approached them and asked them to license the technology.
Everyone is guaranteed use of AES. Besides, it's not like Rijndael is some crappy old cipher (probably), so why use something else?
Some time ago, the developers realized that GNU Emacs would probably never change its major version number (which is 1). So, after some point, instead of "GNU Emacs 1.x.y", they started dropping the 1 (since it was constant information and therefore redundant). So the current release of GNU Emacs is actually 1.21.3, but it's called "GNU Emacs 21.3".
This actually appears to be what Sun is doing now. They've done it before with Solaris/SunOS... twice, in fact.
It's hard to go to concerts when the band never comes over to the US from Japan, and you can't buy merchandise if they won't ship it out of the country either. Believe me, I'd really like to do either, but sometimes it just isn't that easy.
If you live in a modern industrial society, you'll be hard pressed to not give your money to dishonourable people every single day. I'd rather give bands I like whatever meager pittance they get from CD sales then deny them even that, but hey, that's me.
Why does the ENTIRE app need to redraw itself (using huge amounts of network bandwidth) every time I obscure it with a window or hop to another virtual desktop???
It doesn't. X11 has perfectly reasonable ways to specify right now that only a certain region was obscured by another window. That doesn't mean it isn't easier for application developers to interpret Expose events to mean "oh, better redraw everything". If this is really the case, don't blame X, blame the toolkit developers, it's their fault. There is no protocol that will save you from inefficient use of it.
... why the hell can't I simply redirect the output of an already running process to any X-term??? If I have a process running on my PC at school, I should be able to simply redirect the X output over my forwarded SSH port and the running application should smoothly appear on the remote X server.
I've thought about this a bit recently, and it's harder than you think. You have to transfer a lot of data that are represented in implementation-specific fashion (like pending events, graphics areas, etc.) between two servers, so first you need protocol for that. You could probably do that with an X extension. Then, you need to have a way to tell applications "hey, you're no longer connected to server A, go talk to server B instead"... the application needs to respond to that right away, since further references to its stuff in server A will generate BadWindow (or similar) errors. So either every app has to change to listen for a new ChangeServer event, or you have to implement this in Xlib and get everyone who wants to use it to upgrade on all the machines they may want to use.
Another solution is to use something like xmove, which basically connects applications to a "virtual" server which just forwards events to whatever the appropriate real server you want to use is.
The whole point of X wasn't to allow something like that. That's actually fairly complicated compared to plain old network transparency, which just means that I can run an application on any machine on the network and have it display on my workstation.
Slashdot Mirror
That would be a trip. Remember, dupe is short for duplicate. The correct abbreviation for three stories would be "trip", which is short for "triplicate" (which is a real word, yes).
...
The real question is why I'm debating the correct abbreviations for Slashdot editorial errors on Slashdot
Ease of entering non-Western text. OS X is the only operating system I've gotten to easily and effortlessly switch between QWERTY/Dvorak, Japanese, Chinese, and Korean. If I could use it, I could also use about fifty billion other language input methods, including various eastern European languages, Hindi, Arabic, Hebrew, and Thai. The only way I have any idea how you'd do that under Linux/X11 is to multiplex X Input Methods, and I don't know of any applications that do that.
Besides that, Darwin's I/O systems probably aren't as bad as you've heard, speaking from experience. I do lament the lack of virtual desktops, and I'm running 10.2, so I don't have Exposé. OS X really isn't that bad of a system - which is a good thing, as I'm stuck with it for a bit, since my PC just died. (This post is written on my iBook.)
I also have to comment on multilingual support on OS X here, because it's just that good.
Non-western text is supported throughout the operating system transparently. Switching input languages is as simple as pressing Cmd-Space. (You can also use the language menu at the top of the screen, which is similar to the language panel in the Windows taskbar. If you don't want to be able to use Cmd-Space, you can turn that off, but I've never accidentally hit it.) Just go to the International panel in System Preferences and select what languages you want to add to the language menu.
The system uses UTF-8 universally, not UCS-16 like under Windows. I'm not sure if you can use "legacy" character sets, so if Han unification is an issue for you, you'd need to figure out how to deal with that. (I'd bet someone's already had to.)
I absolutely love the Japanese input method. Kanji lookup works quite well, and "adapts" to remember which kana->kanji conversions you use most often. it's pretty much what you'd expect; type kana, hit space, select from the menu that pops up. You can navigate the menu using the keyboard or the mouse. Mac OS X makes Japanese input easy. (I've also had opportunity to try the Traditional Chinese input, it's basically just as good. Korean always screws me up, though, just because I'm not very familiar with the standard Korean romanization systems.)
Oh, and if you don't know a kanji's pronunciation, the Character Palette (kind of like Character Map in Windows, but not at all) lists kanji by radical, sorted by stroke order. You can also get easy access to various symbols (circled katakana, kanji numerals, and stuff like stars from the JIS tables) by looking in the "by Category" tab in the Japanese view. There's also listing by code tables, if you happen to know JIS or Shift JIS codes.
Similar facilities exist in other operating systems (excepting, I'd say, the Character Palette), but I've never had as good experiences with i18n as I have in OS X.
Granted, I'm speccing dual G5 and dual AMD64 systems as possibilities for the next desktop I buy - but I want it to last at least a decade, and have it serve as a desktop system while I'm doing development and content creation at the same time. Most people don't need that sort of power - hell, I'd be perfectly happy with my 866 MHz Pentium 3 based system if the hardware wasn't going.
I've seen it said that testing is not the exact same thing as quality assurance. I don't know what else people associate with QA, but you may want to consider that possibility.
I'm still stuck on IPv7. You know, the one that lets you upload your brain onto the global network.
Mm, Lain.
Certain processor designs can be better suited to different tasks. For example, there was a point when the Alpha beat the shit out of Intel's offerings in integer performance in part because of a significant clock speed gap, but had rather superior floating point performance, even if you extrapolated Intel's performance up to match the Alpha's clock rate. (Aside from issues like performance not scaling perfectly with clock rate, which you should learn about early this semester if this is a real computer architecture class :3 ) Different processors designs can be strong or weak in much different areas.
GPUs aren't meant to be general purpose processors. They're good at doing the sort of calculations that you need to do rotations, shading, and other pretty graphical things, and suck at pretty much everything else. (My unresearched understanding is that this is because GPUs tend to be optimized for floating point performance.) For reasons like this, you probably won't be seeing any add-ons to let you do word processing on your video card while you surf the web any time soon.
Really? I alternately use GNU/Linux on x86 hardware (currently dead, but it was my main machine) and an iBook. The PC, of course, has a "three button" (two buttons and a scroll wheel) optical mouse. The iBook, obviously, has a one-button trackpad. I could easily plug the mouse into the iBook, but I never really need to. I guess I'm not metal enough to turn dumb when I sit behind a Mac :3
...
You're falling into one of the most common "usability" traps - thinking that what is best for you is best for everyone, or at least, talking in a manner that implies you think that way. I think it's a pity how many armchair usability expert discussions degenerate into "THIS IS THE ONE TRUE WAY GODS DAMMIT"
Err, I meant their 32-bit processors. (Their FP was actually 80-bit not-quite-IEEE for a long time, too, so there -_^ )
From the #kernelnewbies fortune file:
I would suggest re-naming "rmbdd()". I _assume_ that "dd" stands for "data
dependent", but quite frankly, "rmbdd" looks like the standard IBM "we
lost every vowel ever invented" kind of assembly lanaguage to me.
I'm sure that having programmed PPC assembly language, you find it very
natural (IBM motto: "We found five vowels hiding in a corner, and we used
them _all_ for the 'eieio' instruction so that we wouldn't have to use
them anywhere else").
- Linus Torvalds on linux-kernel
Even better, the SGI Indys I have play a neat little song when you turn them on.
Of course they do. They were Intel's partner in designing IA-64, after all, and they put a lot of research time and money into it.
Alpha's main wins over Intel architectures at the time were clock speed (DEC hit 500 MHz rather before Intel did, I believe) and floating point performance. Of course, a lot of architectures have better floating point performance than Intel's 32-bit stuff ... though this is less true with the advent of SSE.
Pff, it's not that clear cut, as most people know.
... register windows are neat, but not very RISC) aren't very RISCy at all compared with stuff like MIPS.
Much of the lower level workings of "IA-32" chips are a lot more RISCy than they started out being. More complex instructions are implemented in microcode. On the flip side, architectures like PowerPC (and even SPARC
Neither side won absolutely. This is probably as it should be.
HP doesn't want people buying them, else they might realize that they perform better than comparitively- clocked Itanium kit :3
... what's on the IA-64 roadmap, I wonder.)
(Though to be fair, Itanium 2 was a lot better
I don't :(
You had me willing to try zsh for my next system's default shell until you mentioned multibyte support. Oh, the utter pain in the ass I've gone through with UTF-8 at times ...
Your problem is with a load of stupid fucking script-wanking morons who can't read SuS specs, not with bash.
I don't know if the Rijndael cipher (the algorithm that one the AES contest, essentially) is covered by any patents, but it doesn't matter - the winner agrees to allow anyone to use the cipher regardless of patent coverage, essentially.
RC5, however, does use techniques covered by patents. You'll find that some GNU/Linux distributions, such as Red Hat, don't even include the OpenSSL support for it for that reason. (RH7x also left out IDEA, but unfortunately I don't know about more recent releases.) And I know I've read accounts of people having to build OpenSSL with no-rsa or no-rc5 because RSA approached them and asked them to license the technology.
Everyone is guaranteed use of AES. Besides, it's not like Rijndael is some crappy old cipher (probably), so why use something else?
Emacs.
... twice, in fact.
Some time ago, the developers realized that GNU Emacs would probably never change its major version number (which is 1). So, after some point, instead of "GNU Emacs 1.x.y", they started dropping the 1 (since it was constant information and therefore redundant). So the current release of GNU Emacs is actually 1.21.3, but it's called "GNU Emacs 21.3".
This actually appears to be what Sun is doing now. They've done it before with Solaris/SunOS
It's hard to go to concerts when the band never comes over to the US from Japan, and you can't buy merchandise if they won't ship it out of the country either. Believe me, I'd really like to do either, but sometimes it just isn't that easy.
If you live in a modern industrial society, you'll be hard pressed to not give your money to dishonourable people every single day. I'd rather give bands I like whatever meager pittance they get from CD sales then deny them even that, but hey, that's me.
Are you kidding? What a piece of shit ls! It doesn't even indent into columns properly ;_;
I want my money back ... oh, wait.
Dear AC,
... ".
Slashdot seems to have cut off the rest of your message - the part that starts "because
Best of luck in the future!
(By the way, grandparent was probably talking about OSS/Free.)
Why does the ENTIRE app need to redraw itself (using huge amounts of network bandwidth) every time I obscure it with a window or hop to another virtual desktop???
... why the hell can't I simply redirect the output of an already running process to any X-term??? If I have a process running on my PC at school, I should be able to simply redirect the X output over my forwarded SSH port and the running application should smoothly appear on the remote X server.
... the application needs to respond to that right away, since further references to its stuff in server A will generate BadWindow (or similar) errors. So either every app has to change to listen for a new ChangeServer event, or you have to implement this in Xlib and get everyone who wants to use it to upgrade on all the machines they may want to use.
It doesn't. X11 has perfectly reasonable ways to specify right now that only a certain region was obscured by another window. That doesn't mean it isn't easier for application developers to interpret Expose events to mean "oh, better redraw everything". If this is really the case, don't blame X, blame the toolkit developers, it's their fault. There is no protocol that will save you from inefficient use of it.
I've thought about this a bit recently, and it's harder than you think. You have to transfer a lot of data that are represented in implementation-specific fashion (like pending events, graphics areas, etc.) between two servers, so first you need protocol for that. You could probably do that with an X extension. Then, you need to have a way to tell applications "hey, you're no longer connected to server A, go talk to server B instead"
Another solution is to use something like xmove, which basically connects applications to a "virtual" server which just forwards events to whatever the appropriate real server you want to use is.
The whole point of X wasn't to allow something like that. That's actually fairly complicated compared to plain old network transparency, which just means that I can run an application on any machine on the network and have it display on my workstation.