FWIW, I'm sitting at a mac, using firefox. Safari just isn't as good as firefox(no real surprise for those who tries Konqueror every now and then, just to confirm that KDE is falling behind - Safari uses the same web engine, I believe).
I'd be more than willing to pay an extra $2 for the convenience of packaging and burning to disc. I mean, I'd probably do it anyway myself if I downloaded it. The blank media itself nearly takes up that $2. I say a $2 difference isn't enough to make the download time, time burning, and media worth it
You would if you could, but you can't - that's one of the reasons 12.99 is a pretty bad deal. You can play it on a computer, and that's about it.
An open source software is tested by a whole lot of people over the world and everyone is free to take the code and test if. On the other hand in case of proprietary software this is not the case and is tested by far less number of individuals.
That sounds rather idealistic... The coverage on OSS varies a lot. Most is not tested much, and the testing is not systematic and analyzed, but ad hoc. And if a bug is found, many just shrug and think of it as buggy software, but don't do more about it. There is a world of difference between the high standards of large projects like the linux kernel, apache and eclipse vs. the thousands of small projects found on freshmeat or just googling for something to scratch your itch.
RHEL and SLES are both LSB certified already - the problem is that LSB doesn't specify enough to be useful. An LSB-compliant application needs to include everything outside the LSB scope in itself, which ends up being the OS minus the X libraries and glibc (I'm exagerrating, but not that much).
LSB is the lowest common denominator, and a very static target, in a world of rapid evolvement (e.g. GNOME every 6 months, new compilers, new glibcs etc).
Apt is old tech, and doesn't work too well on Red Hat in e.g. cross platform scenarios. Things like multiarch confuses it to death. Also, occasionally, it wants remove a ton of packages when updating.
I prefer RPM to dpkg as a format capabilitywise, and yum to apt as a front end - and not by a small margin either.
The Opterons don't compete with the Core line at all. Intel hasn't released any server class chips from the Core family yet. Apple still sells G5s in it's server and PowerMac line because of that. We are talking servers not Desktops.
The server part of the new CPUs, Woodcrest, was released before the Core2 and is available in e.g. 1950 and 2950 from Dell. Dell stated they would use the Opteron for 4 way servers, which is what makes most sense.... with Intel's new chip, AMD seem to be behind on the CPUs until you reach 4 and up where HT closes the difference to Intel's bus based offerings.
Intel using a more advanced process than AMD. 65 nm vs 90 nm is irrelevant for users, what matters is the resulting chip - speed, price, heat, features. And, of course, the surrounding platform.
That AMD doesn't use 65 nm yet doesn't make the results skewed - if they had 90 and 65 nm versions shipping now and the 90 nm was worse and the one featured in the test, it would be. At the current state, it's just another option for AMD to improve their product.
Haven't tried Django, but while Ruby on Rails is making progress, it's still no match for the power and flexibility of Zope.
I've been programming python for many years now - I've not used Django, but after reading the docs etc. it looks like yet another "Ruby on rails is popular, let's make something!" which is nowhere near finished. One nice thing about Ruby on Rails is focus - the entire ruby community seems to be on the bandwagon, driving it forward and integrating nicely with it. This means that docs, libraries etc are there for you.
Zope is way too complex... when you know easily how to get most of what you want to do in python scripts from straight database tables, you'll hit your head against the wall for ages converting this from python code to Zope and its evil ZoDB[1]
[1] The one good reason for using ZopeDB is that Python's database libraries need a large overhaul. Consistency is badly needed (making things like quoting etc. driver dependent... which sick mind thought that was a good idea?), and why are there so many drivers? There shouldn't be a need for much more than one for each database - and e.g. in the case of PostgreSQL, that should be the bundled one. pyPgSQL, PyGreSQL, Psycopg, PoPy, Proboscis.... and I'm sure I forgot some. The perl DBI interface was more pleasant to use almost 10 years ago than the python DB interface is today. JDBC also got it right. A de-facto standard python ORM would be nice too.
A free market needs to be protected and enforced by rules. The optimal solution for providers is monopoly.
The telephone market is a very good example of this - much of the value of the service is the ability to connect to others. Thus, if you have large marketshare, there won't be more competition. Game over.
Getting large marketshare? For the telco companies, the incentive to merge would be huge - you could lower competition and obtain monopoly. Just become large enough, kill traffic to other companies (if you have 80% when doing this, the remaining 20% will just become yours) and set the pricing at what makes the most money.
It doesn't do everything - it doesn't support aac, for one. Ogg would be nice too, bug aac is support by a lot of consumer devices and is more widely spread usage among Windows users.
WMP isn't software I enjoy using, but with aac support I hope I could use it instead of the utter crap that is sony's disc2phone.
The Core Duo is the laptop chip released earlier this year, not Intel's next architecture released later this year. It's also used in some desktops, e.g. the iMac and Mac mini.
A bit early for a 2006 list, isn't it? I'd expect the next Intel laptop chip to be better than the Core Duo, and the X2 might be better or worse than the Core 2 Duo - we don't know that yet.
My problem with what you say here - and similar other arguments - is that for example plenty of hardware exist that do not work out of the box and automagically under Windows, be that hdd/raid controller, nic, cameras/tuners and I could just go on
For most hardware additions, you get a CD - put it in, run the starting program and it works. On Linux, that's unfortunately not so yet. And until the kernel driver interface stabilizes, it's unlikely to become so either.
A 3-4 year old CD will still work when you need it to... of course, there is the real problem of the base Windows system often becoming rather unstable after doing this a couple of times.
As for installing a system from scratch - for most Windows users, it's really easy: It's delivered that way. All drivers included. Sure, it can be really painful when it isn't (XP SP2 isn't exactly happy when being installed after Fedora, it just gets to a black screen and stays there - install it first, and it works), but that's not what most users experience.
most boats -- such as mine -- are over 5,000 lbs with trailer and cannot be towed by a compact SUV or pickup since the length will result in a tail wagging the dog situation. a V6 just doesnt cut it. you need a V8 with a full length vehicle to tow it.
How often do you tow such a boat? I my experience, very rarely (they stay at the marina unless you actually sail said boat), and for those occasions having someone else do the job beats having your everyday car suited for the job. I'd also prefer not driving a large truck just because I might buy furniture, better to just order it delivered.
Unfortunately RedHat made the decision in favour of Gnome which was a huge mistake.
A huge mistake? QT at the time was nowhere near free software. Even today, Gnome has a huge license advantange in that you don't need to pay a largish fee to Trolltech to develop anything except GPL software. Also, being C instead of C++-based is good for interoperability with other languages.
That aside, competition is good for both KDE and Gnome - these days, Gnome has the upper hand but the competition ensures that KDE will try even harder to up that bar.
SuSE was a succesful KDE distribution and strong on the desktop in Europe. Mandrake chose KDE. Now we see Ximian "Novell" guys perverting SuSe into a Gnome desktop while we as users never wanted anything but KDE.
"We as users" - don't speak on behalf of anyone but yourself, please. I for one much prefer Gnome. Earlier, because of language bindings and licensing, these days it looks and behaves better too.
And while Mandrake was known as a KDE distro, all their own stuff seemed to be Gnome/gtk.
If you don't believe in their faith, you don't respect it.
There is a difference in respecting their right to believe it and respecting it... because if you don't believe it is true, you believe it to be false: If Muhammed didn't actually talk to an angel, he made it all up and it is all a set of lies (repeat for other religions). That's not respect, even though you respect other people's right to be religious.
No, it isn't. However, for most users, those extra bits are rather pointless - the notebook will run programs just as well as todays 64 bit processors for the lifetime of the laptop.
I'd love a 64 bit notebook, for binary compatibility with 64 bit servers.... however, for almost everyone, that is irrelevant. And while I want 64 bit, I don't think I'd do the sacrifice in other areas and get an AMD-based laptop - the surrounding technologies and the chip itself just aren't as good for laptops. Wireless is likely to be a pain, too: Intel's centrino chips work well, just download the firmware and they're up in e.g. Fedora - not the latest one yet, I guess, but the track record is a good one.
The reason I want dual core, is for smoother multitasking - no more tasks grinding everything to a halt.
64 bit? Yes, please. Not because the laptop needs it, but because when developing for 64 bit systems, I prefer to be running the same on my laptop.
It looks more to me like the big boys can't be bothered to do it, but not because they can't afford it.
I thought both Red Hat Enterprise Linux and sUsE (or however they capitalise it today) Enterprise Server are certified? So the "big boys" did actually bother to do it.
Why would anyone want to have binary compatibility ? The main force of linux (as in unix) is source compatibility.
Because you don't want to compile everything yourself. Just installing something you want, instead of downloading various obscure libraries/compilers the author liked, can be convenient.
Not all programs are open source. I don't think many new games could be open source, and I'd still want them. Many other applications which cost a lot to develop find this an easier way to generate revenue, too. Not every possible market is big enough to generate high quality, highly diverse open development the way Apache and the kernel does.
This, of course, was one of the major downfalls of UNIX, and in part why it failed and how NT and Windows prevailed.
Not innovating and developing would also be a problem... that said, one major problem with LSB is that it doesn't specify enough. An LSB-compliant application needs to bundle a ton of libraries... glibc, kernel interfaces and X can only take you so far, not all the way. And if you started specifying every library, scripting language etc. under the sun, you'd stagnate.
Slashdot Mirror
FWIW, I'm sitting at a mac, using firefox. Safari just isn't as good as firefox(no real surprise for those who tries Konqueror every now and then, just to confirm that KDE is falling behind - Safari uses the same web engine, I believe).
I'd be more than willing to pay an extra $2 for the convenience of packaging and burning to disc. I mean, I'd probably do it anyway myself if I downloaded it. The blank media itself nearly takes up that $2. I say a $2 difference isn't enough to make the download time, time burning, and media worth it
You would if you could, but you can't - that's one of the reasons 12.99 is a pretty bad deal. You can play it on a computer, and that's about it.
An open source software is tested by a whole lot of people over the world and everyone is free to take the code and test if. On the other hand in case of proprietary software this is not the case and is tested by far less number of individuals.
That sounds rather idealistic... The coverage on OSS varies a lot. Most is not tested much, and the testing is not systematic and analyzed, but ad hoc. And if a bug is found, many just shrug and think of it as buggy software, but don't do more about it. There is a world of difference between the high standards of large projects like the linux kernel, apache and eclipse vs. the thousands of small projects found on freshmeat or just googling for something to scratch your itch.
RHEL and SLES are both LSB certified already - the problem is that LSB doesn't specify enough to be useful. An LSB-compliant application needs to include everything outside the LSB scope in itself, which ends up being the OS minus the X libraries and glibc (I'm exagerrating, but not that much). LSB is the lowest common denominator, and a very static target, in a world of rapid evolvement (e.g. GNOME every 6 months, new compilers, new glibcs etc).
Does anyone here have any experience with NIS gateways to LDAP servers, so existing infrastructure can continue to work?
Apt is old tech, and doesn't work too well on Red Hat in e.g. cross platform scenarios. Things like multiarch confuses it to death. Also, occasionally, it wants remove a ton of packages when updating.
I prefer RPM to dpkg as a format capabilitywise, and yum to apt as a front end - and not by a small margin either.
Hell, I can show you museums that show kind, gentle dinosaurs living in harmony with man. So what?
This museum is a parody site, right?
It's not a national holiday in Norway either... and I don't think we're alone.
The Opterons don't compete with the Core line at all. Intel hasn't released any server class chips from the Core family yet. Apple still sells G5s in it's server and PowerMac line because of that. We are talking servers not Desktops.
The server part of the new CPUs, Woodcrest, was released before the Core2 and is available in e.g. 1950 and 2950 from Dell. Dell stated they would use the Opteron for 4 way servers, which is what makes most sense.... with Intel's new chip, AMD seem to be behind on the CPUs until you reach 4 and up where HT closes the difference to Intel's bus based offerings.
A 64 bit CPU might not be faster, but for e.g. developers, running the same environment on the laptops as on servers can be very useful.
Is that ext3 with directory hashing, or without?
Intel using a more advanced process than AMD. 65 nm vs 90 nm is irrelevant for users, what matters is the resulting chip - speed, price, heat, features. And, of course, the surrounding platform.
That AMD doesn't use 65 nm yet doesn't make the results skewed - if they had 90 and 65 nm versions shipping now and the 90 nm was worse and the one featured in the test, it would be. At the current state, it's just another option for AMD to improve their product.
Haven't tried Django, but while Ruby on Rails is making progress, it's still no match for the power and flexibility of Zope.
I've been programming python for many years now - I've not used Django, but after reading the docs etc. it looks like yet another "Ruby on rails is popular, let's make something!" which is nowhere near finished. One nice thing about Ruby on Rails is focus - the entire ruby community seems to be on the bandwagon, driving it forward and integrating nicely with it. This means that docs, libraries etc are there for you.
Zope is way too complex... when you know easily how to get most of what you want to do in python scripts from straight database tables, you'll hit your head against the wall for ages converting this from python code to Zope and its evil ZoDB[1]
[1] The one good reason for using ZopeDB is that Python's database libraries need a large overhaul. Consistency is badly needed (making things like quoting etc. driver dependent... which sick mind thought that was a good idea?), and why are there so many drivers? There shouldn't be a need for much more than one for each database - and e.g. in the case of PostgreSQL, that should be the bundled one. pyPgSQL, PyGreSQL, Psycopg, PoPy, Proboscis.... and I'm sure I forgot some. The perl DBI interface was more pleasant to use almost 10 years ago than the python DB interface is today. JDBC also got it right. A de-facto standard python ORM would be nice too.
A free market needs to be protected and enforced by rules. The optimal solution for providers is monopoly. The telephone market is a very good example of this - much of the value of the service is the ability to connect to others. Thus, if you have large marketshare, there won't be more competition. Game over. Getting large marketshare? For the telco companies, the incentive to merge would be huge - you could lower competition and obtain monopoly. Just become large enough, kill traffic to other companies (if you have 80% when doing this, the remaining 20% will just become yours) and set the pricing at what makes the most money.
It doesn't do everything - it doesn't support aac, for one. Ogg would be nice too, bug aac is support by a lot of consumer devices and is more widely spread usage among Windows users. WMP isn't software I enjoy using, but with aac support I hope I could use it instead of the utter crap that is sony's disc2phone.
The Core Duo is the laptop chip released earlier this year, not Intel's next architecture released later this year. It's also used in some desktops, e.g. the iMac and Mac mini. A bit early for a 2006 list, isn't it? I'd expect the next Intel laptop chip to be better than the Core Duo, and the X2 might be better or worse than the Core 2 Duo - we don't know that yet.
My problem with what you say here - and similar other arguments - is that for example plenty of hardware exist that do not work out of the box and automagically under Windows, be that hdd/raid controller, nic, cameras/tuners and I could just go on
For most hardware additions, you get a CD - put it in, run the starting program and it works. On Linux, that's unfortunately not so yet. And until the kernel driver interface stabilizes, it's unlikely to become so either. A 3-4 year old CD will still work when you need it to... of course, there is the real problem of the base Windows system often becoming rather unstable after doing this a couple of times.
As for installing a system from scratch - for most Windows users, it's really easy: It's delivered that way. All drivers included. Sure, it can be really painful when it isn't (XP SP2 isn't exactly happy when being installed after Fedora, it just gets to a black screen and stays there - install it first, and it works), but that's not what most users experience.
The easiest way to do it is not to do it at all.
most boats -- such as mine -- are over 5,000 lbs with trailer and cannot be towed by a compact SUV or pickup since the length will result in a tail wagging the dog situation. a V6 just doesnt cut it. you need a V8 with a full length vehicle to tow it.
How often do you tow such a boat? I my experience, very rarely (they stay at the marina unless you actually sail said boat), and for those occasions having someone else do the job beats having your everyday car suited for the job. I'd also prefer not driving a large truck just because I might buy furniture, better to just order it delivered.
Unfortunately RedHat made the decision in favour of Gnome which was a huge mistake.
A huge mistake? QT at the time was nowhere near free software. Even today, Gnome has a huge license advantange in that you don't need to pay a largish fee to Trolltech to develop anything except GPL software. Also, being C instead of C++-based is good for interoperability with other languages.
That aside, competition is good for both KDE and Gnome - these days, Gnome has the upper hand but the competition ensures that KDE will try even harder to up that bar.
SuSE was a succesful KDE distribution and strong on the desktop in Europe. Mandrake chose KDE. Now we see Ximian "Novell" guys perverting SuSe into a Gnome desktop while we as users never wanted anything but KDE.
"We as users" - don't speak on behalf of anyone but yourself, please. I for one much prefer Gnome. Earlier, because of language bindings and licensing, these days it looks and behaves better too. And while Mandrake was known as a KDE distro, all their own stuff seemed to be Gnome/gtk.
If you don't believe in their faith, you don't respect it.
There is a difference in respecting their right to believe it and respecting it... because if you don't believe it is true, you believe it to be false: If Muhammed didn't actually talk to an angel, he made it all up and it is all a set of lies (repeat for other religions). That's not respect, even though you respect other people's right to be religious.
My question is, is the CoreDuo 64 bit?
No, it isn't. However, for most users, those extra bits are rather pointless - the notebook will run programs just as well as todays 64 bit processors for the lifetime of the laptop.
I'd love a 64 bit notebook, for binary compatibility with 64 bit servers.... however, for almost everyone, that is irrelevant. And while I want 64 bit, I don't think I'd do the sacrifice in other areas and get an AMD-based laptop - the surrounding technologies and the chip itself just aren't as good for laptops. Wireless is likely to be a pain, too: Intel's centrino chips work well, just download the firmware and they're up in e.g. Fedora - not the latest one yet, I guess, but the track record is a good one.
The reason I want dual core, is for smoother multitasking - no more tasks grinding everything to a halt. 64 bit? Yes, please. Not because the laptop needs it, but because when developing for 64 bit systems, I prefer to be running the same on my laptop.
It looks more to me like the big boys can't be bothered to do it, but not because they can't afford it.
I thought both Red Hat Enterprise Linux and sUsE (or however they capitalise it today) Enterprise Server are certified? So the "big boys" did actually bother to do it.
Why would anyone want to have binary compatibility ? The main force of linux (as in unix) is source compatibility.
This, of course, was one of the major downfalls of UNIX, and in part why it failed and how NT and Windows prevailed.
Not innovating and developing would also be a problem... that said, one major problem with LSB is that it doesn't specify enough. An LSB-compliant application needs to bundle a ton of libraries... glibc, kernel interfaces and X can only take you so far, not all the way. And if you started specifying every library, scripting language etc. under the sun, you'd stagnate.