embedded developers really need a completely separate distribution from a mainstream desktop/server one like debian.
something like an arm/68k(coldfire)/etc embedded distribution would be more beneficial to embedded development in general. something built from the ground up around diet libc etc for example, ditching X11 and everything else useless for embedded systems. taking framebuffer development to the next level etc.
embedded architectures hold back debian, and debian holds back embedded architectures. forking would be beneficial to both.
sadly its ia64 performance isnt very good either. the compilers still arent up to snuff generating EPIC code and may never be. current research indicates EPIC (at least as implemented by ia64) may never reach anywhere near its performance goals.
also many of the problems EPIC aimed to solve a decade ago when it was started, turned out to be non issues or have long since been solved (similar to how many of the SPARC 'design wins' have since become completely irrelevant)
as far as deployment goes, ia64 would be something like a distant 6th or 7th, after mips, parisc and alpha. with ia32, sparc and x86_64 in the top 3 slots.
pbx with PIN number. anyone who doesnt enter the PIN gets silently dumped to voicemail -- your phone never rings. the PIN gets them to immediately ring through, bypassing voicemail.
osx isnt linux nor is it even bsd. its some bizarre hybrid which was bsd-ish but has weird mutated incompatibilities such as missing dlopen() (recently fixed, but was missing for a long time).
not to mention the mess that is bundles. yes i know its legacy from nextstep and yes it sucks less than classic macos resource/data forks. but that doesn't make it right:)
also anything which links to the Carbon framework needs access to the GUI. unfortunately a lot of the fundamental OSX API is only available in Carbonlib so many character based apps may end up needing to link to it.
Imagine things like grep and sed refusing to work unless they can open a connection to X11. That's the kind of weirdness you get with porting stuff to OSX:-/
osx might make a fine desktop client but as a dedicated server os it leaves much to be desired.
december 15 1989 noriega declared war on the us, and the us was more than happy to oblige him.
you also got your facts quite wrong -- he was holed up in the vatican embassy not the presidential compound. unless you're suggesting noriega siezed the vatican embassy as his property.
there are religious blasphemy laws still on the books in the USA, and i'd bet there are laws on the books in australia too. so its illegal in saudi arabia, iran, USA and probably australia.
there was a case in the UK as recently as 1979 that resulted in a criminal blasphemy conviction. (the maximum penalty in the UK is imprisonment for life).
again... don't buy it. you don't agree with the vendor's EULA, so don't buy the product.
the only way vendors are going to learn its unacceptable is for people to stop buying their encumbered products. as long as you line their pockets, you're supporting their bad behavior and encouraging them to do more.
or to make it more plain: there's more than one vendor of razor. there's more than one vendor of printer. there's more than one vendor of oranges. there's more than one vendor of software.
stop supporting vendors who sell encumbered products and buy products from vendors who don't encumber their products.
so in other words, you're open to extraditing americans to saudi arabia because they violated saudi religious heresy laws?
how about extraditing salman rushdie to iran? they have a long standing death sentence on him for violating iranian law. he _is_ guilty as all hell, after all.
how about a shuttle SFF with a p4 cpu. hyperthread cpu if you really care.
that will demolish the dual eden in every conceivable way, including interrupt handling. and if you're worried about power consumption, use a pentium-m. it will still demolish the via performance wise and interrupt wise and use almost no power to boot.
SFF will also reduce the space taken to almost nothing.
try more like, a 1ghz via is equivalent to a 500mhz p2.
a p3 is a (relatively) fast chip, a p2 is not.
i definitely wouldnt use a dual 1ghz eden for a desktop workstation. i'd use a single cpu pentium-m -- much faster and more responsive and better performance.
actually ive several numerous multiprocessor workstations. dual celeron (BP6), two dual athlons (S2460s), and now dual opteron (S2875)
yes it means you can do multiple tasks simultaneously. but on a via eden, each task is _really_ slow. so you can do a bunch very slow tasks simultaneously. woo fucking hoo.
yes, it's better than a single cpu eden, but the responsiveness of a dual cpu eden will still be much, much slower than a single processor athlon or pentium-m.
midrange desktop replacement? uh, no. the via is a *really* slow cpu. two of them wont help responsiveness that much. last time i tested an eden cpu, it performed roughly the same as a p2 at half the mhz. (eg 800mhz eden performed roughly the same as a p2/400).
the via cpu target is set-top boxes and embedded applications. it makes a poor desktop cpu, where your data processing requirements are considerably higher than a PVR or car stereo system.
even via knows better, they aren't targeting the desktop with this because they know it isn't right.
for a midrange desktop you'll get more out of a single pentium-m...
that's not too bad, compared to the 25w of intel's pentium-m.
also remember than intel understates their peak power while amd overstates theirs. dont recall who did the test, i think it was the german c't mag who found the discrepancies between claimed and actual power consumption.
Slashdot Mirror
more like cocaine snorted through rolled up hundred dollar bills.
embedded developers really need a completely separate distribution from a mainstream desktop/server one like debian.
something like an arm/68k(coldfire)/etc embedded distribution would be more beneficial to embedded development in general. something built from the ground up around diet libc etc for example, ditching X11 and everything else useless for embedded systems. taking framebuffer development to the next level etc.
embedded architectures hold back debian, and debian holds back embedded architectures. forking would be beneficial to both.
sadly its ia64 performance isnt very good either. the compilers still arent up to snuff generating EPIC code and may never be. current research indicates EPIC (at least as implemented by ia64) may never reach anywhere near its performance goals.
also many of the problems EPIC aimed to solve a decade ago when it was started, turned out to be non issues or have long since been solved (similar to how many of the SPARC 'design wins' have since become completely irrelevant)
everything about ia64 is antithetical to risc.
as far as deployment goes, ia64 would be something like a distant 6th or 7th, after mips, parisc and alpha. with ia32, sparc and x86_64 in the top 3 slots.
it's just an extension. you know, extension? like people have been easily and trivially remembering for 2-3 decades now?
pbx with PIN number. anyone who doesnt enter the PIN gets silently dumped to voicemail -- your phone never rings. the PIN gets them to immediately ring through, bypassing voicemail.
simple. elegant. failsafe.
you're welcome.
osx isnt linux nor is it even bsd. its some bizarre hybrid which was bsd-ish but has weird mutated incompatibilities such as missing dlopen() (recently fixed, but was missing for a long time).
:)
:-/
not to mention the mess that is bundles. yes i know its legacy from nextstep and yes it sucks less than classic macos resource/data forks. but that doesn't make it right
also anything which links to the Carbon framework needs access to the GUI. unfortunately a lot of the fundamental OSX API is only available in Carbonlib so many character based apps may end up needing to link to it.
Imagine things like grep and sed refusing to work unless they can open a connection to X11. That's the kind of weirdness you get with porting stuff to OSX
osx might make a fine desktop client but as a dedicated server os it leaves much to be desired.
I can't believe you got modded *Informative* for that.
you must be new around here.
december 15 1989 noriega declared war on the us, and the us was more than happy to oblige him.
you also got your facts quite wrong -- he was holed up in the vatican embassy not the presidential compound. unless you're suggesting noriega siezed the vatican embassy as his property.
Aahahahha. You fucking FRIED that luser. Sadly I have no mod points to spare :-/
there are religious blasphemy laws still on the books in the USA, and i'd bet there are laws on the books in australia too. so its illegal in saudi arabia, iran, USA and probably australia.
there was a case in the UK as recently as 1979 that resulted in a criminal blasphemy conviction. (the maximum penalty in the UK is imprisonment for life).
next?
again... don't buy it. you don't agree with the vendor's EULA, so don't buy the product.
the only way vendors are going to learn its unacceptable is for people to stop buying their encumbered products. as long as you line their pockets, you're supporting their bad behavior and encouraging them to do more.
or to make it more plain: there's more than one vendor of razor. there's more than one vendor of printer. there's more than one vendor of oranges. there's more than one vendor of software.
stop supporting vendors who sell encumbered products and buy products from vendors who don't encumber their products.
keep the pressure on. they can't keep it up forever, and eventually they'll slip up, make a mistake, then you can nail them.
or look for legal loopholes to abuse.
dont get mad, get even.
Some software comes with really annoying copy protection that seems to punish people who purchase a license.
so dont buy it then. and dont warez it either. and tell people not to do business with that company.
so in other words, you're open to extraditing americans to saudi arabia because they violated saudi religious heresy laws?
how about extraditing salman rushdie to iran? they have a long standing death sentence on him for violating iranian law. he _is_ guilty as all hell, after all.
it's not treason. but it is a felony punishable by 10 years in prison.
how about a shuttle SFF with a p4 cpu. hyperthread cpu if you really care.
that will demolish the dual eden in every conceivable way, including interrupt handling. and if you're worried about power consumption, use a pentium-m. it will still demolish the via performance wise and interrupt wise and use almost no power to boot.
SFF will also reduce the space taken to almost nothing.
shuttle has been making small, fast, and quiet for some years now.
the hard drive is the loudest thing in my shuttle SFF, and that's already a very quiet maxtor with FDB. you can't even hear the fan at all.
keep in mind each eden 1ghz processor is roughly equivalent to a 500mhz p2 (or 500mhz k6, if you arent familiar with p2's).
your 800mhz p3 would grind the dual 1ghz eden to dust.
try more like, a 1ghz via is equivalent to a 500mhz p2.
a p3 is a (relatively) fast chip, a p2 is not.
i definitely wouldnt use a dual 1ghz eden for a desktop workstation. i'd use a single cpu pentium-m -- much faster and more responsive and better performance.
i/o doesn't work that way. at least if you use DMA like any modern system does. maybe it would help if you had a dual 486 running PIO or something :)
actually ive several numerous multiprocessor workstations. dual celeron (BP6), two dual athlons (S2460s), and now dual opteron (S2875)
yes it means you can do multiple tasks simultaneously. but on a via eden, each task is _really_ slow. so you can do a bunch very slow tasks simultaneously. woo fucking hoo.
yes, it's better than a single cpu eden, but the responsiveness of a dual cpu eden will still be much, much slower than a single processor athlon or pentium-m.
making the CS server smp aware is hard, there's not much that can be parallelized. and what can be parallelized wont gain much from smp.
midrange desktop replacement? uh, no. the via is a *really* slow cpu. two of them wont help responsiveness that much. last time i tested an eden cpu, it performed roughly the same as a p2 at half the mhz. (eg 800mhz eden performed roughly the same as a p2/400).
the via cpu target is set-top boxes and embedded applications. it makes a poor desktop cpu, where your data processing requirements are considerably higher than a PVR or car stereo system.
even via knows better, they aren't targeting the desktop with this because they know it isn't right.
for a midrange desktop you'll get more out of a single pentium-m...
that's not too bad, compared to the 25w of intel's pentium-m.
also remember than intel understates their peak power while amd overstates theirs. dont recall who did the test, i think it was the german c't mag who found the discrepancies between claimed and actual power consumption.