You and I are probably from Africa originally, so should we be able to go to Africa and establish a state here?
Who care what occured milleniums ago? Only recent history matter.
Re:Python, not anymore. Ruby, maybe but doubt it
on
Learning Perl, 4th Ed.
·
· Score: 3, Insightful
Well of course if you're used to Perl, OO programming will seem very hard to learn:-)
For learning OO programming, I'd advise 'Object-Oriented Software Construction' it use Eiffel as its programming language, and is quite old but it is very, very clear about why OO programming makes sense.
And for me, Python or Ruby (preferably) are better than Perl because those language have a readable syntax by default, in Perl you have to fight the language to produce readable code, thus a big majority of Perl code is just unreadable, barf.
Well, while I agree that WinXP blue screen of death are rare, there are still big issue with system corruption.
A friend of mine had a registry corruption problem, and none of the backup could be used to solve it --> reinstallation. Recently for some reason, I couldn't boot anymore and had to repair the installation, it worked, but I've never figured why the corruption appeared..
So while XP is very stable, sometimes it just blow up spontaneously, something that doesn't really occur with Linux: once it work, it'll stay working (except with filesystem corruption, but those are usually caused by faulty hardware).
Not to say that Linux is perfect: upgrades are sometimes risky. And on both software still tend to crash a bit too much (on Linux, for a desktop, having the kernel running but being forced to logoff is as bad as if the kernel has crashed so uptime comparison is not good enough), and both must be patched for security far too often.
> Software won't be a problem with Apple's developers plan with being able to compile both PPC and x86 into the same build.
Yeah right, and of course, and the upgrade of all your current PPC-only software to the version which support both PPC and x86 will be free (as in beer)? Didn't think so too.. So there *is* a difference if you buy a PPC-Mac now and then upgrade to a x86-MAC, you'll have to pay for the upgrade of all your software. Depending on the number of software you're using, this may or may not be a problem, but stop saying that 'there is no difference'!
I noticed that the x86 board you refer to has half the DRAM,no 10/100 Ethernet interface, maybe this help for the power consumption? (it probably doesn't explain the whole difference)
What would be interesting also is comparing the SpecInt (and also SpecFP for fun) of these two processors.. Clock speed isn't a good performance indicator: traditionnaly RISCs have been more powerful than x86 at a given clockspeed, but I don't know if this is the case here.
>I LOVE GNU/linux as my desktop, but it sure isn't ready for the masses.
Well I fear that this struggle with HW will last a long time.. And IMHO Linux is definitely not ready to use without a (broadband) Internet connection.
>Word processor- check. Untrue, compatiblity with Word is not yet good enough and it is quite heavy (in 1.2 version, I'll try 2.0 when it will be stable)
>Stability- check. Could be improved: while the kernel is stable, many application are not very good, which for a desktop is nearly the same thing.
>Administration- check. *Very debatable*, many things are rougher due to bad HW support (non-redistributable firmware for example, closed source drivers). But some configuration are also much too difficult, for example the configuration of a QWERTY keyboard to get accent with compose key is a nightmare.. Quite often when you want to do something not so common, you get in the gray area where it becomes *very difficult* poorly documented, poorly integrated: KDE/Gnome does it thing, X does its thing and it's very difficult to sort the mess..
Windows while poorly documented seems a bit more polished, not that it don't have poor decisions too: the guy who decided to hide 'Open with..' unless you do shift+right click should be shot.
Uh, you're confusing things, self-assembling is a mean not an end. The goal is to build lots of nanobots able to work with molecules directly. The only way to build enough nanobots to be useful is self-assembly, but self-assembling in itself is not interesting. It is also likely that self-assembling is only useful for step 0: with self-assembly you build a factory of nanobots, those nanobots are powerful but complex and not very efficient, so you use this nanofactory to build a specialised factory to produce efficiently the product you want.
>Also consider that bootup is usually the time to detect new hardware.
Most of the time, there is no new hardware, so why slow down the common case for the exceptionnal case?
>In fact, im quite happy with the 20-30 seconds i get with windows xp.
Well, it's just that you don't need much to be happy, I had 14s boot time with BeOS in a Celeron333 (with a fully responsive desktop not a cheat like WinXP does)..
I don't know: if the name brand guys screw up something, then it means that the majority of users will find that it suck, so yes in this case "Linux's something" will suck.
That said, *I* don't find that fonts on Linux really suck (it used to!), I use both WindowsXP and Linux and don't find much difference. But on the other hand I've seen a comparison on fonts on the web between Linux and OS-X (don't remember where, sorry) and OS-X was much, much better than Linux..
Now of course, I don't really trust a few screenshot seen on the web (didn't really care as I'm not going to buy a PPC: I like games), but if it is true, then fonts on Linux do suck compared to OS-X. Maybe we'll see more comparison with the 'MacPCs' when they'll arrive..
I don't know what's worse, the constant drivel of people to request a screenshot even in modifications not related to GUIs (I run the 2.6 kernel. Do you have a screenshot? WTF??) or that it was moderated +5 insightful..
At work, we have the choice between KDE and Gnome, that's all. About 3/4 of the users use KDE even though Gnome is the default on RHE, which I find amusing.. Both look the same speed to me (ie unresponsive).
I'm not sure I'll be able to see the new KDE soon: at work we won't change soon, and at home when I tried Kunbutu, I fried my Windows install (no data lost but it is still quite annoying) and KUnbutu wouldn't start! Maybe I'll try a live CD but for judging the speed it isn't ideal, of course..
Makes no mistake: I like programming on Linux, but I remember that BeOS on Celeron 333MHz was far more responsive than Linux is (as far as I have seen currently), which is really a pity.
You know, he is not the only one who rejected Linux, I did too.. Too much of a pain to use Linux at home, so I switched to WinXP, amusingly at work we've gone from Solaris to Linux so I'm still using Linux, but what I see at work doesn't particulary push me to use Linux again at home: the desktop (KDE on RHE3) feels *slow* on a 3GHz P4 with 2GB of RAM!!
While I like using Linux for servers, for desktop I don't think it is very good..
Well if AMD don't have a similar RISC part, is-it going to be used? If not, the RISC layer would be just excess bagage.. Basically you're describing the compatibility mode of the itanium but x86 performance wasn't soo good..
Also now that x86 have 16 registers instead of 8, I wonder if x86-64 --> RISC style would be such an improvement? Maybe not so much..
As much as I hate x86 (it's fugly) I think that we're stuck with it ad vitam eternam, for the PC and the servers at least.
Uh, how the PA-RISC, PPC, Sparc failures in the PC or server has anything related to the RISC concept?
If memory serves, the G5 has 1/4 the number of transistor of the P4 and it was competitive in performance. The problem is more that even with much less transistors the economy of scales of x86 (and the intense competition between AMD and Intel), made the price very low, thus allowing x86 to compete with RISCs where it matters in the price/performance ratio, Windows and software compatibility made the rest..
Have you noticed how any new CPU is RISC? ARM, SH, etc.. Even VLIW follow RISC conventions (fixed instruction length, load/store architecture, etc..). So it really is a better CPU architecture than CISC but being better doesn't necessarily that you win, as shown by many examples..
Slashdot Mirror
> tend to use ~300 MB on average, and I rarely have anything extra running besides Firefox, gaim, and AVG.
Well if Mozilla if any indication, Firefox is the culprit: its use gobs of memory.
> Anyway, just from reading the article, I am not inclined to spend the money on upgrading. As of now, none of the new features seem very impressive.
Agreed.
Bah, this is a very weak historical claim.
You and I are probably from Africa originally, so should we be able to go to Africa and establish a state here?
Who care what occured milleniums ago? Only recent history matter.
Well of course if you're used to Perl, OO programming will seem very hard to learn :-)
For learning OO programming, I'd advise 'Object-Oriented Software Construction' it use Eiffel as its programming language, and is quite old but it is very, very clear about why OO programming makes sense.
And for me, Python or Ruby (preferably) are better than Perl because those language have a readable syntax by default, in Perl you have to fight the language to produce readable code, thus a big majority of Perl code is just unreadable, barf.
Well, while I agree that WinXP blue screen of death are rare, there are still big issue with system corruption.
A friend of mine had a registry corruption problem, and none of the backup could be used to solve it --> reinstallation.
Recently for some reason, I couldn't boot anymore and had to repair the installation, it worked, but I've never figured why the corruption appeared..
So while XP is very stable, sometimes it just blow up spontaneously, something that doesn't really occur with Linux: once it work, it'll stay working (except with filesystem corruption, but those are usually caused by faulty hardware).
Not to say that Linux is perfect: upgrades are sometimes risky.
And on both software still tend to crash a bit too much (on Linux, for a desktop, having the kernel running but being forced to logoff is as bad as if the kernel has crashed so uptime comparison is not good enough), and both must be patched for security far too often.
> Software won't be a problem with Apple's developers plan with being able to compile both PPC and x86 into the same build.
Yeah right, and of course, and the upgrade of all your current PPC-only software to the version which support both PPC and x86 will be free (as in beer)?
Didn't think so too..
So there *is* a difference if you buy a PPC-Mac now and then upgrade to a x86-MAC, you'll have to pay for the upgrade of all your software.
Depending on the number of software you're using, this may or may not be a problem, but stop saying that 'there is no difference'!
Sorry, but I doubt very much that emulation with PALCode is efficient compared to a CPU 95% identical with the target is trying to "emulate".
Sure with enough CPU power, you can emulate anything but power consumption matter on embedded equipment.
>They should build an Alpha clone!
Why? The Alpha ISA was good ok, but x86 victory shows clearly that software compatibility is more important than a good ISA.
For the embedded market, MIPS-compatibility is more important than Alpha's compatibility, and its ISA is correct (better than x86 anyway).
> Debian provides a great platform to provide support for us non-x86 platform users.
In this case, Debian support is not so great forcing to use the ARM in little endian while its "native" byte ordering is big endian..
I know technically the ARM is capable of doing both, but I think there is a small loss of performance using it in big endian mode..
I noticed that the x86 board you refer to has half the DRAM,no 10/100 Ethernet interface, maybe this help for the power consumption? (it probably doesn't explain the whole difference)
What would be interesting also is comparing the SpecInt (and also SpecFP for fun) of these two processors..
Clock speed isn't a good performance indicator: traditionnaly RISCs have been more powerful than x86 at a given clockspeed, but I don't know if this is the case here.
>I LOVE GNU/linux as my desktop, but it sure isn't ready for the masses.
Well I fear that this struggle with HW will last a long time..
And IMHO Linux is definitely not ready to use without a (broadband) Internet connection.
>Word processor- check.
Untrue, compatiblity with Word is not yet good enough and it is quite heavy (in 1.2 version, I'll try 2.0 when it will be stable)
>Stability- check.
Could be improved: while the kernel is stable, many application are not very good, which for a desktop is nearly the same thing.
>Administration- check.
*Very debatable*, many things are rougher due to bad HW support (non-redistributable firmware for example, closed source drivers).
But some configuration are also much too difficult, for example the configuration of a QWERTY keyboard to get accent with compose key is a nightmare..
Quite often when you want to do something not so common, you get in the gray area where it becomes *very difficult* poorly documented, poorly integrated: KDE/Gnome does it thing, X does its thing and it's very difficult to sort the mess..
Windows while poorly documented seems a bit more polished, not that it don't have poor decisions too: the guy who decided to hide 'Open with..' unless you do shift+right click should be shot.
Uh, you're confusing things, self-assembling is a mean not an end.
The goal is to build lots of nanobots able to work with molecules directly.
The only way to build enough nanobots to be useful is self-assembly, but self-assembling in itself is not interesting.
It is also likely that self-assembling is only useful for step 0: with self-assembly you build a factory of nanobots, those nanobots are powerful but complex and not very efficient, so you use this nanofactory to build a specialised factory to produce efficiently the product you want.
>Also consider that bootup is usually the time to detect new hardware.
Most of the time, there is no new hardware, so why slow down the common case for the exceptionnal case?
>In fact, im quite happy with the 20-30 seconds i get with windows xp.
Well, it's just that you don't need much to be happy, I had 14s boot time with BeOS in a Celeron333 (with a fully responsive desktop not a cheat like WinXP does)..
Well, I wouldn't worry too much about this case: French judges have *very little* patience for these kind of frivolous/stupid complaint..
>meanwhile most serious OS level and game development continues to be in C or C++
And the developpers still don't manage to reduce the number of security flaws found in C or C++ programs..
I'd really like if D (or Eiffel, or Ada) would have success, but my hopes aren't great: not big enough "hype machine" pushing the language.
Uh, last time I looked sparse wouldn't have been necessary if the kernel had been coded in Ada, but maybe I haven't looked closely enough..
C is grat for kernel programming?
If that's the case, why did Linus made a tool to uncover type error in the kernel?
I like C a lot, but it doesn't scale very much as shown by the bandaid that people invent when the programs get big..
I don't know: if the name brand guys screw up something, then it means that the majority of users will find that it suck, so yes in this case "Linux's something" will suck.
That said, *I* don't find that fonts on Linux really suck (it used to!), I use both WindowsXP and Linux and don't find much difference.
But on the other hand I've seen a comparison on fonts on the web between Linux and OS-X (don't remember where, sorry) and OS-X was much, much better than Linux..
Now of course, I don't really trust a few screenshot seen on the web (didn't really care as I'm not going to buy a PPC: I like games), but if it is true, then fonts on Linux do suck compared to OS-X.
Maybe we'll see more comparison with the 'MacPCs' when they'll arrive..
Thanks for setting things straight.
I don't know what's worse, the constant drivel of people to request a screenshot even in modifications not related to GUIs (I run the 2.6 kernel. Do you have a screenshot? WTF??) or that it was moderated
+5 insightful..
At work, we have the choice between KDE and Gnome, that's all.
About 3/4 of the users use KDE even though Gnome is the default on RHE, which I find amusing..
Both look the same speed to me (ie unresponsive).
I'm not sure I'll be able to see the new KDE soon: at work we won't change soon, and at home when I tried Kunbutu, I fried my Windows install (no data lost but it is still quite annoying) and KUnbutu wouldn't start!
Maybe I'll try a live CD but for judging the speed it isn't ideal, of course..
Makes no mistake: I like programming on Linux, but I remember that BeOS on Celeron 333MHz was far more responsive than Linux is (as far as I have seen currently), which is really a pity.
What's make you think this is "ploy"?
You know, he is not the only one who rejected Linux, I did too..
Too much of a pain to use Linux at home, so I switched to WinXP, amusingly at work we've gone from Solaris to Linux so I'm still using Linux, but what I see at work doesn't particulary push me to use Linux again at home: the desktop (KDE on RHE3) feels *slow* on a 3GHz P4 with 2GB of RAM!!
While I like using Linux for servers, for desktop I don't think it is very good..
For the cell, your description sounds good, but for the XBox?
Well if AMD don't have a similar RISC part, is-it going to be used?
If not, the RISC layer would be just excess bagage.. Basically you're describing the compatibility mode of the itanium but x86 performance wasn't soo good..
Also now that x86 have 16 registers instead of 8, I wonder if x86-64 --> RISC style would be such an improvement? Maybe not so much..
As much as I hate x86 (it's fugly) I think that we're stuck with it ad vitam eternam, for the PC and the servers at least.
Uh, how the PA-RISC, PPC, Sparc failures in the PC or server has anything related to the RISC concept?
If memory serves, the G5 has 1/4 the number of transistor of the P4 and it was competitive in performance.
The problem is more that even with much less transistors the economy of scales of x86 (and the intense competition between AMD and Intel), made the price very low, thus allowing x86 to compete with RISCs where it matters in the price/performance ratio, Windows and software compatibility made the rest..
Have you noticed how any new CPU is RISC?
ARM, SH, etc.. Even VLIW follow RISC conventions (fixed instruction length, load/store architecture, etc..).
So it really is a better CPU architecture than CISC but being better doesn't necessarily that you win, as shown by many examples..