I checked the numbers, did you? Clock for clock, the PA-Risc outdoes the alpha at integer ops. For database systems, this is generally more relevant than floating point speed.
Yeah, and I checked the other numbers too. All the evidence I see suggests that the top reported Alpha numbers are higher than the top reported HP numbers. In fact, Alpha seems to be ahead of HP in spite of the fact that the most recent offical TPC numbers for Alpha are almost two years old. (I'm really looking forward to seeing transaction numbers for the GS series.)
I fail to see how "work per clock cycle" is a more relevant measure of performance that "work per unit wall clock time" (aka "throughput").
Clarification: DS vs. GS series
on
New Mega Alphas
·
· Score: 1
The big announcement (what this article about) is the GS series, which is separate and totally different from the DS series (of which the DS10L is a member).
Don't get me wrong, the DS machines are great, they just don't have the new system architecture that makes the GS series so awesome (which is what all the hubub is about).
What sucks is that the alpha architecture hasn't kept up in the clock speed race. Ghz alphas were supposed to be out by now too.
Yeah well, they do exist, but as with the system integration parts in the ES line, there are yield problems. The transition to the fabless model since the sale of Digital Semi hasn't been as perfect as it could have been, and scaling down the feature size has turned up more bugs than expected in the 21264. Not like it matters though, because Alpha is still #1 in performance. If you care about MHz over actual performance, then you need to go back to college and learn a thing or two about computer architecture.
Of course there's also Alpha's 64-bit advantage, which does make a big difference in important applications (gene sequencing/discovery, data warehousing, etc.).
Historically, the alpha has had the highest clock speed of any chip on the market. No longer. This is a bummer since they don't do as much per clock as, say, a PA-Risc system.
Let me repeat myself: check the real performance numbers. Even though nothing from the GS line is even in there yet, Alpha is still way out in front.
And as for "doing more in a clock cycle," no, they really don't. We have an acronym for what they actually do: VLIW. It's not more parallelism (that comes from how many instructions you issue in a cycle), it's just more explicit information about operation independence (which it turns out doesn't work so well). It didn't work in the '80s (Multiflow RIP), it sucks today in HP machines, and it's going to suck tomorrow in IA-64. (Not that it matters though. Intel could sell a rock with wires coming out of it and people would still buy it.)
"With IA-64, Intel makes a 20 year leap forward in technology: from 1960 to 1980."
I use Motif for a bunch of internally developed and used tools. However, since the work I do is only used internally, the company is unwilling to shell out license fess for us to get a recent version. Our customers can buy Motif 2, but we don't get it on the inside. Thus we are trapped with the bugs and primitive feature set of Motif 1.2.
When I saw this headline, I though "At last! Now I can drag our interfaces into the early '90s!" But no, not on our OS of choice. That really frosts me. Thanks for nothing, [so-called but not really] Open Group!
[At the risk of letting the cat out of the bag too early...]
Anybody who finds this interesting might want to take a look at Vesta. It's an advanced revision control/build system developed at Compaq's Systems Research Center (the people who brought you the Personal Jukebox and co-developed the Itsy). I've been using it for over a year, and going back to make/CVS style development now feels downright primitive. Among some of Vesta's cooler features:
Automatic language-independent perfect dependency checking. (You never even have to even think about dependencies, and it really can't get them wrong.)
Guaranteed build repeatability. (Dependencies on everything, including compiler and library versions, are captured. If you've ever done a build in the past, you'll be able to repeat it and get an equivalent result.)
Build incrementality that works site wide. (If anyone using the same server has compiled a file, nobody else needs to wait for it to be compiled, because the result is already available. This also cuts down on total disk usage, because there aren't redundant copies of object files lying around.)
It's not available today, but there's a lot of talk about releasing it.
Designing a good user interface is very hard, because it requires that you imagine how different people will interact with your software. It requires a lot of thinking ahead and considering different cases and understanding what may go on inside the heads of your users. A lot of people have lists of principles, here's some of mine:
The user shouldn't be able to shoot themselves in the foot. People, even experienced technical people, make mistakes. Often. This is why providing undo is far better than asking "Are you sure you want to do this?" (Usually, people don't even listen to questions like that and simply respond with "yes".) These problems get really bad when it isn't clear that the user is making a choice they won't be able to back out of. (I once had a friend who messed the driver for the CD-ROM on his Windows machine. Where was the driver software he needed to install: on a CD which came with the machine.)
Make the choices visible. Invisible or inaccessible controls suck. If I might need to change it, there should be a way to do so. Unless you're certain the user won't need it, don't hide it or turn it off. When something is disabled, the relationship between it and whatever controls whether its an option should be obvious. The worst is controls that can only be changed sometimes, but affect the outcome when they are inaccessible. (Yes, I've seen GUIs with this all too often.)
Provide feedback early. The smaller the temporal separation between a user making a choice and the time the users observe the consequences, the better. The longer the delay, the harder it is for the user to get the system adjusted to their needs. (Imagine, for example, trying to adjust a light with a dimmer switch if you couldn't see the light from the dimmer. It would be an iterative process of adjust, run and go check the light, run back and adjust, run back and check. Frustrating to say the least.) In other words: an interactive process beats a batch one. (This is also one reason why people choose interpreted languages over compiled ones: faster turnaround.)
Think about usability from the beginning. Software engineers tend to focus on functionality first and leave usability to the back end. This is why, for example,/etc is such a rats nest of shell scripts and configuration files, each with its own format and oddities. They weren't designed for uability, they evolved to provide functionality. Sure, they work, but when something goes wrong or when you need to change something, figuring it out takes way too long. (And don't kid yourself, the number of people who fully grok the/etc on their system is really small.)
And another thing: Usability is not just for newbies. The other day I built a custom kernel for my Alpha, and I had a hard time figuring out why aboot (an Alpha bootloader) said to me:
aboot: expected 1, not 2 program headers
Turns out, the kernel image was too big, and I had to move some things into modules in order to get it to work. There are two obvious problems here:
I had to ask somebody else who had the same problem before, which shouldn't have been necessary. One person should always be able to debug a problem. If it requires this sort of "oral tradition," then the error messages, comments, and documentation are inadequate.
Why exactly is there this spooky limit on the size of the kernel, and how does it relate to my choices? If it was clear to me when I'd been configuring the kernel, that would have been great. (Imagine if the X configurator said "Whoa there, you kernel's gonna be too big to load, maybe you should make sound support into a module?") If it warned me when I was building it, that wouldn't have been too bad. (Obviously, it would be easy to make a post-build tool which checks for this problem.) But no, I had to attempt to boot this kernel in order to find out that it wouldn't work. (Like I said, provide feedback early.)
Anyone who designs user interfaces (which really includes any software which will ever be used by humans) should read Donald Norman's "The Psychology/Design of Everyday Things." It will change the way you look at the computers you use and the software you write.
If you think this is cool, you might also like this miniature all-in-one PC. It uses the ~1 watt (read: convection cooled) MediaGX from National Semiconductor (originally by Cyrix). It doesn't have as much computational muscle as the Espresso, but there are a lot of applications that don't need a 400-500MHz Celeron (i.e. a router/firewall/mini house server). Plus this one comes with built in 10/100BaseT.
I've been trying to figure out how to build a silent (read: convection cooled) Linux firewall/router to serve my cable modem connection to my other machines. I'd like to do it with a StrongARM part, but I can't seem to find a solution with a reasonable price (sub $500 total).
I've looked at the Chalice CATS, which could definitely do the job, but is more than $500 just for the board. LART looks pretty cool, but seems to have support for only one ethernet adapter at this time (and I have no idea how much it would actually cost). The NetWinder is also very cool, but it starts at around $1400 (and I've heard that they are not exactly silent). I've seen some info on machines from Acorn which might fit the bill, but I haven't been able to get their website to load.
Does anybody out there know of a low-cost StrongARM device which can run Linux and can support an IDE drive and two ethernet adapters?
Yes, I've looked at the fixed purpose firrewall boxes that do this, but I work for a large company with a constantly in-flux Intranet tunneling strategy, so I want enough control of my firewall to make sure I can keep up with the protocol du jour. I've also considered doing an insane i-opener hack (one USB ethernet adapter, one parallel port ethernet adapter), although I might as well just pick up a cheap box with a socket 7 motherboard and slap a Winchip in there myself to get the low power consumption. I'd have to take some other steps to quiet such a box, but it may be the best solution in my price range. Still, I think a StongARM solution would be much cooler.
Repeat after me: Mhz only has any validity as a benchmark within an architecture.
It's even worse than that: clock speed is only useful for comparison within one implementation of an architecture. The quirks of each design (number of functional units, cache and virtual register file sizes, number of instructions fetched/queued/dispatched per cycle, etc.) have a big impact on how speed translates to actual performance. For eaxample, if you took a PII and a PIII running at the same clock speed, you would expect to get difference performance.
A 400Mhz PII is NOT 33% faster than a 300Mhz PII. It's maybe 10%.
That sort of result usually indicates that you've hit a bottleneck somewhere between 300MHz and 400 MHz. A good guess is that it's something that doesn't scale linerally with the processor speed, like cache size or memory bandwidth or even I/O bandwidth (depending on your application). In an overall system architecture designed to scale well, you would expect to see closer to linear scaling with the clock speed (up to whatever point the system was designed to scale to, and not counting poorly tuned applications).
As for SPECint/SPECfp for the processor in the system for the CEA, you won't find them yet. If you read the article carefully, you'll note that the system isn't due to be delivered for more than a year. It's going to use 0.18 micron 21264's, which are being manufactured in small quantities for testing and QA but haven't shipped yet. You can bet they'll be faster than any GHz x86 though.
Hard links don't get dereferenced, unless (in the example above), you do something like $ cp a c
I admit, I oversimplified. It does depend on exactly how you manipulate a. However, most text editors (at least the ones I use on a regular basis) will get you a new inode when you save because they don't actually edit the file contents in place. (They're more like deleting the file and then writing the new one.) And I doubt many people actually edit their configuration files with cat >>.
Maybe Rob should consider consolidating and/or eliminating the now-you're-talking department and the now-we're-getting-somewhere department, because this is at least the third time that this exact same device has been a headline on/.:
Then when I change foo.conf, and hose my system, I can't restore it by using foo.conf.old, because that file was changed when I changed foo.conf!
My guess is that the feature described would be more analogous to making hard links (ln) than symbolic links (ln -s). (If you don't know what that means, you should go read the ln(1) man page, and possibly link(2) as well.) In your example, if I say "ln foo.conf foo.conf.old", no new storage is taken up, but it looks like there are two copies. Then when I edit foo.conf, the underlying file is de-referenced, but hangs around because foo.conf.old still references it. A new file is created to hold my edited version.
Of course this is all conjecture, as the article doesn't go into enough detail to tell what's really going on. However, I doubt that even Microsoft would do it in quite so brain-dead a manner as to cause the problem suggested.
The only thing that bugs me is that I only have a single-button mouse. There's supposed to be a key toggle that activates a right-click, but it doesn't work for some reason. I've had several linuxheads try to remap the key combo, but it just doesn't want to go -- thus rendering the Gimp and some windowmanagers useless.
When I first started using LinuxPPC this was a big issue for me (being a long-time X user). I specifically went out and bought a Kensington Thinking mouse and it works great. It's an ADB device with 4 buttons. (Unfortunately, LinuxPPC only recognizes the first three, and I was so looking forward to binding actions to MB4.:-) You may have a hard time getting your hands on one though, as their website says that it's been discontinued. Supposedly you should be able to use their ADB Turbo Mouse (a trackball also with 4 buttons), but I can't vouch for that.
If you read the ADB specs, there are actually two pointer protocols: the original one and a newer multi-button protocol. Theoretically, LinuxPPC will work correctly with any device that supports the new protocol (handler 4, if I remember correctly). Of course, you probably will have a difficult time finding out if a particular product supports this without just buying it and trying it.
USB devices are a different thing altogether (about which I know very little).
Is it just me, or has this not yet hit their FTP servers? I've been putting off upgrading my installation until they unveiled their next major release, but this still doesn't seem to be up there. The closest thing I can find is the installer for their last release.
...would be MacOS X on Alpha. An OS from the company with the best usability combined with the world's fastest microprocessor. Imagine the possibilities.
Re:Why not just use the Crusoe as a G4?
on
Darwin on Crusoe?
·
· Score: 1
If you read the Transmeta technical white paper, it's implied that the TM3120 and TM5400 (and their associated CodeMorphing software) were designed with x86 as their sole target ISA. (Otherwise, why not bill it as a universal processor and give the software layer the ability to run multiple other ISAs?) While it might be possible the get them to emulate other processor architectures (by writing a new CodeMorphing layer), my guess is that it would turn out sub-optimally.
The whole point of Transmeta's design philosophy is to pick your target application domain, and optimize the hardware, software, and hardware/software division for the constraints of that domain specifically. Executing x86 and PowerPC instructions are different enough that I would expect the Transmeta answer to be "make a new hardware core and a new CodeMorphing layer".
There's been talk about actually open sourcing Motif. I'd be just as happy to see it die a much deserved death as a 1980's relic
As much as I agree with you that Motif's death is overdue, X itself is just as much a "1980's relic", if not more so. Why people revile one and not the other, I don't understand. Just a few of the major things that bug me on a daily basis:
Totally braindead multi-monitor support. Go ahead, yell "Xinerama!" so I can tell you that it's a pathetic band-aid. The Mac has had a sensible system that actually works (even with monitors with different sizes and bit depths) for more than a decade.
The division of work between the client and server is totally wrong. Come on, a network packet for every key press and mouse move? Talk about your overly chatty protocols. The bulk of the interface code should execute on the machine that the keyboard, mouse, and monitor are attached to. Anybody remember NeWS?
A configuration system that's nearly impossible to use. The X resource system, while powerful, makes about as much sense as the Windows registry. Figuring out what resource to set ranges from difficult to impossible. The management of resource settings ("throw 'em all in.Xdefaults") makes keeping track of them require way too much effort.
Personally, I find the increasingly pervasive notion that "Linux" is synonymous with "x86" even more infuriating than the notion that "Linux" is equivalent to "RedHat".
I just spent 10 minutes hunting through IBM's Java sites for their Linux JDK installation requirements. I knew it was going to say "x86 processor", but I shouldn't have had to look so hard to find that out.
I don't mean to flame, or to suggest that a company has any sort of obligation to support non-x86 Linux platforms. It just seems to me that if a company is providing software for x86 Linux systems, then that should be prominently stated in press releases, web pages, etc. They shouldn't say just "Linux" unless they mean all Linux systems (PowerPC, Alpha, StrongARM, 68k, etc.), which they never do unless they're releasing source.
and don't send plain email. you have to send a pdf file or a word document
For those of you without a copy of Word or WordPerfect handy (which I suspect may be a lot of us *nix users), it seems that Adobe has a free service which will turn any file into a PDF and e-mail it to you. You get 10 conversions per e-mail address you register with them. It accepts text and HTML uploads, and the output from an HTML file is pretty reasonable. (I had some trouble with a file with links in it though, so you might want to get rid of any before using this.)
I also think many of the criticism MS received for bundling IE and windows is a direct result from the fact that some people for various reasons don't symphatize with MS and dislike most of their products (for varioous reasons).
The fact remains that bundling the two adds value. I.e. the resulted integrated product provides is more valuable than the two seperate products.
Wrong. To say that adding IE to Windows adds value is a vast oversimplification. The value is not in having IE in particular, it's the capabilities of ubiquitous browser access which MS added to Windows.
This is not, from a user's perspective, specific to IE. It most certainly could have been done in such a way that you could use many different browsers with it. Look at the way MIME types are handled on UNIX systems through your mailcap file. Look at the way browser invocation is handled on the Mac through Internet Config and Apple's Internet Address Detectors.
The right answer is simple: define an dispatch interface that allows you to plug in any appropriate receiver. Microsoft specifically chose not to do this. They chose to implement this in a manner which is IE-specific and locks out competing browsers. Why did they do this? Because They wanted the browser market for themselves. Why could they do it? Because they have such a huge share of the desktop OS market.
The claim that you could also achieve this with a third party product is also not correct. MS like it or not has several non standard features in IE and in the integrated OS there are several things that depend on those features and would be difficult to provide with a third party browser.
The only reason that it doesn't work as well with 3rd-party browsers is that MS chose to implement something which only works with their product. Did it make good business sense? Certainly. But that does not make it ethically right.
Being anti MS is easy that's probably why it's so popular these days. In my eyes they are a normal company that operate their business like all their big competitors do.
Wrong. They are not a normal company, they are the largest software company in the world, and the provider of the dominant OS platform. That is absolutely not normal, it is exceptional.
Microsoft needs to grow up and learn that the rules change when you're #1. You can't play the game the same way anymore. It's one thing for small companies to stab each other in the back. It's quite another for the sole supplier of a core technology (the OS) to decide to crush another company's product.
The whole point of this post: compete on quality not in court.
The real point: It is mean, nasty, unethical, and illegal to use monopoly or near-monopoly power in one market to affect a related but separate market. That is precisely what MS has done, and it is precisely why they are in court now.
Nobody who can find their compiler with both hands was fooled for a minute by that "it's a part of the OS" argument. Browsers have always been and always will be applications. What is part of the OS is underlying services, such as inter-application communication. All MS has done is implement a special, IE-specific kind of IAC. Choosing to lock out competitors in this way was not just illegal, it was a poor engineering choice, and it was made for market rather than technical reasons. That's what annoys me most about the whole thing.
As someone who not only played but worked on maps and a map generator for the Marathon 2 engine, I'm wondering why they didn't release the Marathon Infinity code. (The Marathon series was a trilogy, with Marathon Infinity being the third and final chapter.) Infinity can load M2 map files, although there are some subtle differences in the engine and the texture sets were reworked. The main difference was the fact that Infinity allowed you to embed a physics model with each level in a map. (With Marathon 1 & 2, the phsyics model was stored in a separate file and was the same for all levels.) This allowed you to change the rules of the game from one level to the next, which was pretty cool.
P.S. For anybody who doesn't know, the best part about the Marathon series is it's story. I've always found the id games to be a real bore because they were missing this key element. I guess Bungie spoiled me.
[For those who don't know, IMSA is a state-wide, residential magnet school for grades 10-12, with less than 1000 total students. It requires an application, recommendations, and the SAT to gain admittance. While math and science take a prominent place in its name, it also has excellent humanities and social studies programs. The idea was to provide a better educational environment for gifted high school students.]
IMSA, which first opened in 1986, is now halfway through it's thirteenth year. It was an experiment when it was first created. Over the years, it has changed and adapted on a number of levels. Now it's more a fixture of the Illinois educational system.
Certainly, improving the education of future generations is as important and controversial a topic today as it was then. Do you feel that the IMSA experiment was a success? Would you now advocate starting more programs like it in other states? Would you say that, over its 13 year history, the institution has maintained the correct focus, or have they perhaps lost sight of their original goals in order to ensure their own survival and continued funding?
Slashdot Mirror
Yeah, and I checked the other numbers too. All the evidence I see suggests that the top reported Alpha numbers are higher than the top reported HP numbers. In fact, Alpha seems to be ahead of HP in spite of the fact that the most recent offical TPC numbers for Alpha are almost two years old. (I'm really looking forward to seeing transaction numbers for the GS series.)
I fail to see how "work per clock cycle" is a more relevant measure of performance that "work per unit wall clock time" (aka "throughput").
The big announcement (what this article about) is the GS series, which is separate and totally different from the DS series (of which the DS10L is a member).
Don't get me wrong, the DS machines are great, they just don't have the new system architecture that makes the GS series so awesome (which is what all the hubub is about).
Yeah well, they do exist, but as with the system integration parts in the ES line, there are yield problems. The transition to the fabless model since the sale of Digital Semi hasn't been as perfect as it could have been, and scaling down the feature size has turned up more bugs than expected in the 21264. Not like it matters though, because Alpha is still #1 in performance. If you care about MHz over actual performance, then you need to go back to college and learn a thing or two about computer architecture.
Of course there's also Alpha's 64-bit advantage, which does make a big difference in important applications (gene sequencing/discovery, data warehousing, etc.).
Let me repeat myself: check the real performance numbers. Even though nothing from the GS line is even in there yet, Alpha is still way out in front.
And as for "doing more in a clock cycle," no, they really don't. We have an acronym for what they actually do: VLIW. It's not more parallelism (that comes from how many instructions you issue in a cycle), it's just more explicit information about operation independence (which it turns out doesn't work so well). It didn't work in the '80s (Multiflow RIP), it sucks today in HP machines, and it's going to suck tomorrow in IA-64. (Not that it matters though. Intel could sell a rock with wires coming out of it and people would still buy it.)
"With IA-64, Intel makes a 20 year leap forward in technology: from 1960 to 1980."
I was really psyched until I read the fine print. I happen to work for one of the companies that originally worked on Motif (or rather the company that bought them). We get Motif 1.2 for free, but have to pay licensing fees for Motif 2.
I use Motif for a bunch of internally developed and used tools. However, since the work I do is only used internally, the company is unwilling to shell out license fess for us to get a recent version. Our customers can buy Motif 2, but we don't get it on the inside. Thus we are trapped with the bugs and primitive feature set of Motif 1.2.
When I saw this headline, I though "At last! Now I can drag our interfaces into the early '90s!" But no, not on our OS of choice. That really frosts me. Thanks for nothing, [so-called but not really] Open Group!
[At the risk of letting the cat out of the bag too early...]
Anybody who finds this interesting might want to take a look at Vesta. It's an advanced revision control/build system developed at Compaq's Systems Research Center (the people who brought you the Personal Jukebox and co-developed the Itsy). I've been using it for over a year, and going back to make/CVS style development now feels downright primitive. Among some of Vesta's cooler features:
It's not available today, but there's a lot of talk about releasing it.
- The user shouldn't be able to shoot themselves in the foot. People, even experienced technical people, make mistakes. Often. This is why providing undo is far better than asking "Are you sure you want to do this?" (Usually, people don't even listen to questions like that and simply respond with "yes".) These problems get really bad when it isn't clear that the user is making a choice they won't be able to back out of. (I once had a friend who messed the driver for the CD-ROM on his Windows machine. Where was the driver software he needed to install: on a CD which came with the machine.)
- Make the choices visible. Invisible or inaccessible controls suck. If I might need to change it, there should be a way to do so. Unless you're certain the user won't need it, don't hide it or turn it off. When something is disabled, the relationship between it and whatever controls whether its an option should be obvious. The worst is controls that can only be changed sometimes, but affect the outcome when they are inaccessible. (Yes, I've seen GUIs with this all too often.)
- Provide feedback early. The smaller the temporal separation between a user making a choice and the time the users observe the consequences, the better. The longer the delay, the harder it is for the user to get the system adjusted to their needs. (Imagine, for example, trying to adjust a light with a dimmer switch if you couldn't see the light from the dimmer. It would be an iterative process of adjust, run and go check the light, run back and adjust, run back and check. Frustrating to say the least.) In other words: an interactive process beats a batch one. (This is also one reason why people choose interpreted languages over compiled ones: faster turnaround.)
- Think about usability from the beginning. Software engineers tend to focus on functionality first and leave usability to the back end. This is why, for example,
/etc is such a rats nest of shell scripts and configuration files, each with its own format and oddities. They weren't designed for uability, they evolved to provide functionality. Sure, they work, but when something goes wrong or when you need to change something, figuring it out takes way too long. (And don't kid yourself, the number of people who fully grok the /etc on their system is really small.)
And another thing: Usability is not just for newbies. The other day I built a custom kernel for my Alpha, and I had a hard time figuring out why aboot (an Alpha bootloader) said to me:- aboot: expected 1, not 2 program headers
Turns out, the kernel image was too big, and I had to move some things into modules in order to get it to work. There are two obvious problems here:Anyone who designs user interfaces (which really includes any software which will ever be used by humans) should read Donald Norman's "The Psychology/Design of Everyday Things." It will change the way you look at the computers you use and the software you write.
If you think this is cool, you might also like this miniature all-in-one PC. It uses the ~1 watt (read: convection cooled) MediaGX from National Semiconductor (originally by Cyrix). It doesn't have as much computational muscle as the Espresso, but there are a lot of applications that don't need a 400-500MHz Celeron (i.e. a router/firewall/mini house server). Plus this one comes with built in 10/100BaseT.
[Moderators, prepare your offtopic flags]
I've been trying to figure out how to build a silent (read: convection cooled) Linux firewall/router to serve my cable modem connection to my other machines. I'd like to do it with a StrongARM part, but I can't seem to find a solution with a reasonable price (sub $500 total).
I've looked at the Chalice CATS, which could definitely do the job, but is more than $500 just for the board. LART looks pretty cool, but seems to have support for only one ethernet adapter at this time (and I have no idea how much it would actually cost). The NetWinder is also very cool, but it starts at around $1400 (and I've heard that they are not exactly silent). I've seen some info on machines from Acorn which might fit the bill, but I haven't been able to get their website to load.
Does anybody out there know of a low-cost StrongARM device which can run Linux and can support an IDE drive and two ethernet adapters?
Yes, I've looked at the fixed purpose firrewall boxes that do this, but I work for a large company with a constantly in-flux Intranet tunneling strategy, so I want enough control of my firewall to make sure I can keep up with the protocol du jour. I've also considered doing an insane i-opener hack (one USB ethernet adapter, one parallel port ethernet adapter), although I might as well just pick up a cheap box with a socket 7 motherboard and slap a Winchip in there myself to get the low power consumption. I'd have to take some other steps to quiet such a box, but it may be the best solution in my price range. Still, I think a StongARM solution would be much cooler.
It's even worse than that: clock speed is only useful for comparison within one implementation of an architecture. The quirks of each design (number of functional units, cache and virtual register file sizes, number of instructions fetched/queued/dispatched per cycle, etc.) have a big impact on how speed translates to actual performance. For eaxample, if you took a PII and a PIII running at the same clock speed, you would expect to get difference performance.
That sort of result usually indicates that you've hit a bottleneck somewhere between 300MHz and 400 MHz. A good guess is that it's something that doesn't scale linerally with the processor speed, like cache size or memory bandwidth or even I/O bandwidth (depending on your application). In an overall system architecture designed to scale well, you would expect to see closer to linear scaling with the clock speed (up to whatever point the system was designed to scale to, and not counting poorly tuned applications).
As for SPECint/SPECfp for the processor in the system for the CEA, you won't find them yet. If you read the article carefully, you'll note that the system isn't due to be delivered for more than a year. It's going to use 0.18 micron 21264's, which are being manufactured in small quantities for testing and QA but haven't shipped yet. You can bet they'll be faster than any GHz x86 though.
I admit, I oversimplified. It does depend on exactly how you manipulate a. However, most text editors (at least the ones I use on a regular basis) will get you a new inode when you save because they don't actually edit the file contents in place. (They're more like deleting the file and then writing the new one.) And I doubt many people actually edit their configuration files with cat >>.
Maybe Rob should consider consolidating and/or eliminating the now-you're-talking department and the now-we're-getting-somewhere department, because this is at least the third time that this exact same device has been a headline on /.:
My guess is that the feature described would be more analogous to making hard links (ln) than symbolic links (ln -s). (If you don't know what that means, you should go read the ln(1) man page, and possibly link(2) as well.) In your example, if I say "ln foo.conf foo.conf.old", no new storage is taken up, but it looks like there are two copies. Then when I edit foo.conf, the underlying file is de-referenced, but hangs around because foo.conf.old still references it. A new file is created to hold my edited version.
Of course this is all conjecture, as the article doesn't go into enough detail to tell what's really going on. However, I doubt that even Microsoft would do it in quite so brain-dead a manner as to cause the problem suggested.
When I first started using LinuxPPC this was a big issue for me (being a long-time X user). I specifically went out and bought a Kensington Thinking mouse and it works great. It's an ADB device with 4 buttons. (Unfortunately, LinuxPPC only recognizes the first three, and I was so looking forward to binding actions to MB4. :-) You may have a hard time getting your hands on one though, as their website says that it's been discontinued. Supposedly you should be able to use their ADB Turbo Mouse (a trackball also with 4 buttons), but I can't vouch for that.
If you read the ADB specs, there are actually two pointer protocols: the original one and a newer multi-button protocol. Theoretically, LinuxPPC will work correctly with any device that supports the new protocol (handler 4, if I remember correctly). Of course, you probably will have a difficult time finding out if a particular product supports this without just buying it and trying it.
USB devices are a different thing altogether (about which I know very little).
Is it just me, or has this not yet hit their FTP servers? I've been putting off upgrading my installation until they unveiled their next major release, but this still doesn't seem to be up there. The closest thing I can find is the installer for their last release.
If you read the Transmeta technical white paper, it's implied that the TM3120 and TM5400 (and their associated CodeMorphing software) were designed with x86 as their sole target ISA. (Otherwise, why not bill it as a universal processor and give the software layer the ability to run multiple other ISAs?) While it might be possible the get them to emulate other processor architectures (by writing a new CodeMorphing layer), my guess is that it would turn out sub-optimally.
The whole point of Transmeta's design philosophy is to pick your target application domain, and optimize the hardware, software, and hardware/software division for the constraints of that domain specifically. Executing x86 and PowerPC instructions are different enough that I would expect the Transmeta answer to be "make a new hardware core and a new CodeMorphing layer".
Unfortunately, thanks to features like JavaScript mouse-overs, unless you dig through the HTML you may not see the real URL. For example, this:
Might actually be this:
As much as I agree with you that Motif's death is overdue, X itself is just as much a "1980's relic", if not more so. Why people revile one and not the other, I don't understand. Just a few of the major things that bug me on a daily basis:
When I went to college, I was lucky enough to actually take an english course on science fiction. It's still offered at the University of Illinois and has a homepage complete with a syllabus, which includes the list of texts used throughout the course.
Personally, I find the increasingly pervasive notion that "Linux" is synonymous with "x86" even more infuriating than the notion that "Linux" is equivalent to "RedHat".
I just spent 10 minutes hunting through IBM's Java sites for their Linux JDK installation requirements. I knew it was going to say "x86 processor", but I shouldn't have had to look so hard to find that out.
I don't mean to flame, or to suggest that a company has any sort of obligation to support non-x86 Linux platforms. It just seems to me that if a company is providing software for x86 Linux systems, then that should be prominently stated in press releases, web pages, etc. They shouldn't say just "Linux" unless they mean all Linux systems (PowerPC, Alpha, StrongARM, 68k, etc.), which they never do unless they're releasing source.
For those of you without a copy of Word or WordPerfect handy (which I suspect may be a lot of us *nix users), it seems that Adobe has a free service which will turn any file into a PDF and e-mail it to you. You get 10 conversions per e-mail address you register with them. It accepts text and HTML uploads, and the output from an HTML file is pretty reasonable. (I had some trouble with a file with links in it though, so you might want to get rid of any before using this.)
Wrong. To say that adding IE to Windows adds value is a vast oversimplification. The value is not in having IE in particular, it's the capabilities of ubiquitous browser access which MS added to Windows.
This is not, from a user's perspective, specific to IE. It most certainly could have been done in such a way that you could use many different browsers with it. Look at the way MIME types are handled on UNIX systems through your mailcap file. Look at the way browser invocation is handled on the Mac through Internet Config and Apple's Internet Address Detectors.
The right answer is simple: define an dispatch interface that allows you to plug in any appropriate receiver. Microsoft specifically chose not to do this. They chose to implement this in a manner which is IE-specific and locks out competing browsers. Why did they do this? Because They wanted the browser market for themselves. Why could they do it? Because they have such a huge share of the desktop OS market.
The only reason that it doesn't work as well with 3rd-party browsers is that MS chose to implement something which only works with their product. Did it make good business sense? Certainly. But that does not make it ethically right.
Wrong. They are not a normal company, they are the largest software company in the world, and the provider of the dominant OS platform. That is absolutely not normal, it is exceptional.
Microsoft needs to grow up and learn that the rules change when you're #1. You can't play the game the same way anymore. It's one thing for small companies to stab each other in the back. It's quite another for the sole supplier of a core technology (the OS) to decide to crush another company's product.
The real point: It is mean, nasty, unethical, and illegal to use monopoly or near-monopoly power in one market to affect a related but separate market. That is precisely what MS has done, and it is precisely why they are in court now.
Nobody who can find their compiler with both hands was fooled for a minute by that "it's a part of the OS" argument. Browsers have always been and always will be applications. What is part of the OS is underlying services, such as inter-application communication. All MS has done is implement a special, IE-specific kind of IAC. Choosing to lock out competitors in this way was not just illegal, it was a poor engineering choice, and it was made for market rather than technical reasons. That's what annoys me most about the whole thing.
As someone who not only played but worked on maps and a map generator for the Marathon 2 engine, I'm wondering why they didn't release the Marathon Infinity code. (The Marathon series was a trilogy, with Marathon Infinity being the third and final chapter.) Infinity can load M2 map files, although there are some subtle differences in the engine and the texture sets were reworked. The main difference was the fact that Infinity allowed you to embed a physics model with each level in a map. (With Marathon 1 & 2, the phsyics model was stored in a separate file and was the same for all levels.) This allowed you to change the rules of the game from one level to the next, which was pretty cool.
P.S. For anybody who doesn't know, the best part about the Marathon series is it's story. I've always found the id games to be a real bore because they were missing this key element. I guess Bungie spoiled me.
1994, actually. In terms of usability, it's just as true today.
While perhaps not everyone here is aware of it, I remember your involvement with the early history of the Illinois Mathematics and Science Academy.
[For those who don't know, IMSA is a state-wide, residential magnet school for grades 10-12, with less than 1000 total students. It requires an application, recommendations, and the SAT to gain admittance. While math and science take a prominent place in its name, it also has excellent humanities and social studies programs. The idea was to provide a better educational environment for gifted high school students.]
IMSA, which first opened in 1986, is now halfway through it's thirteenth year. It was an experiment when it was first created. Over the years, it has changed and adapted on a number of levels. Now it's more a fixture of the Illinois educational system.
Certainly, improving the education of future generations is as important and controversial a topic today as it was then. Do you feel that the IMSA experiment was a success? Would you now advocate starting more programs like it in other states? Would you say that, over its 13 year history, the institution has maintained the correct focus, or have they perhaps lost sight of their original goals in order to ensure their own survival and continued funding?
In any case, thanks. I felt it helped me.
--K. Schalk, IMSA calss of 1990