There are several reasons why Google Update runs all the time that you're missing, but the crucial assumption you seem to be making is that the process is "constantly running using up resources".
All of this handwaving is unnecessary, since the problem is "ethical" in a sense. The user does not want to have google updater running for whatever reason => the user should be able to remove it whenever he wants. I suppose the rootkit sony installed back in the day didn't consume too much resources either.
Please, more comments, or I'll be forced to read the actual article. I don't want to be kicked off slashdot for RtFA...
Try to avoid reading the article, because it's pretty nonsensical. It may be the beer I was drinking, but I didn't really get what they are talking about.
Want to compile a list of companies with Finnish offices and a track record of solid, secure, verifiable e-voting systems with a tangible prototype to impress the decision-gorillas?
Give me 500EUR and I'll hack up such an e-voting system in one workday.
Anyone knows a good, uptodate, userfriendly and binary distro that still uses KDE3.5?
Debian "Lenny". Though I think I'd recommend staying with 8.04 instead of going to Lenny, having tried both I'd say many things just work better on 8.04.
There is still new hardware out there that Linux doesn't support out of the box with existing ones? What hardware is that? -- Serious question.
The atheros wlan card on eee pc 900 (how's that for mainstream hardware?).
It has a driver (so theoretically is 'supported out of the box'), but it's just not good enough. The connection through it has intermittent brown-outs and it's slow, whereas the ndiswrapper works fine (nevermind the fact that it's a performance hog).
Just tried with the ubuntu Jaunty beta, and the ath5k driver still has the same problem.
Apart from that, the amount of cluelessness in this whole topic is staggering. Seems like some windows fanboy site referenced this article, and all the winboy trolls came out of the woods immediately.
I've often thought that lots of gaming really is something that could be handled on low-powered devices. Take, for example, X3's trading - you really don't need to have access to the 3d engine to plot trade routes etc. Of course it would still be the same game, as opposed to "gimmicks" like merely sharing a number (amount of money available).
GNU/FreeBSD. FreeBSD kernel (and libc?) + GNU userland (instead of the BSD userland). There's no linux involved (except perhaps the linux syscall emulation)
So what is the part of the gnu userland that makes it important enough to use in the title of the OS? Compiler?
GNOME want to deliver a desktop which is easy to use, which works, which is modeled for users. Therefore the philosophy is more good defaults and less options.
KDE has another philosophy therefore there are more options and switches.
None of this is very relevant for the discussion at hand - this is about rewriting the underlying framework as opposed to polishing the existing one.
Settings & such are to be implemented in individual apps.
Ok, so how many (especially desktop) apps will be faster by an amount observable by the user? I still think this wont be many.
Depends how much the apps depend on the file system (both reading and writing). Many desktop apps depend on reading a lot, and they benefit from better ordering of the data in file system.
Of course you only need to care about this if you care about file system performance in the first place - I don't think ext3 is going anywhere soon.
As to the "this seems to be what the doctor ordered for slash drives". Does this imply the number of reads and writes to the drive is reduced?
Yes - if you delay the writes more, you have a better idea what actually needs to hit the disk in the end, so you can cut away unnecessary writes. Since you can also combine several writes, you need to erase fewer blocks (though this one is more speculation than actual knowledge).
I would rather Firefox developers focusing in making the code more stable and threadable instead of adding unneeded process overhead.
So instead of creating a more robust architecture, squash every little bug in the codebase?
Processes are the most efficient cleanup mechanism around (short of power cycle). This is why operating systems don't come to screeching halt all the time, even if there are tons of bugs in userspace software.
Sadly, processes are underutilized, now that kids think threads/mainloop dispatchers and memory sharing are the way to go. Hopefully Chrome taught them a lesson.
Sun's folks created a GPL-incompatible license specifically to have some pieces that Linux doesn't have.
Wrong! The GNU folks created a license that was incompatible with other licenses.
GPL was around, you know, a little bit earlier than CDDL.
The fact that CDDL license is incompatible with Solaris' only relevant competitor seems quite convenient an "accident", whatever people may be saying to you.
Often, the problem with companies is that information doesn't get spread around. People work on their own projects in secret, never bothering to spread their knowledge. Perhaps this will urge some of the those to pay some attention to being useful for other employees as well, as opposed to just getting their own little project done.
Sure, the current build system is a crappy maze of perl scripts but that will change (already has for some people) with the foundation to SBSv2 which is very, very fast and designed to exploit multiple cores.
This is something I've been wondering about - why does it take ages to implement something that could have been done with a bit of SCons tweaking?
A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature.
I think losing that "feature" is a feature in itself.
I'm currently using xfce, and the fact that the session manager thinks it works annoys me quite a bit. I have in fact turned it off, but it still chooses to open a bunch of firefox sessions before wlan is up (and NetworkManager is querying the password in the background).
Another useful "feature" of session management is opening up 17 terminals on bootup. This feature just needs to go. I'm not a big fan of Gnome, but they got this thing right;-).
Symbian does very well in running on small device. It gives the program features to keep their application using small amounts of systems resources and tries to keep them robust.
Too bad these "features" actually make Symbian heavier than other operating systems. CleanupStack leads to bigger binaries than auto_ptr, you need write of code to do anything related to UI, you need heavyweight client / server architecture for many simple things (lots of context switchs), active objects are much heavier weight (and more error prone) than normal callbacks,...
The fact is that Symbian's relative success has been mostly due to financial, rather than technical reasons.
And it's not like there has been much choice in the mobile space previously. We've had the simple proprietary OS's of every manufacturer, half-assed locked down linux variants of Motorola, MSFT products and Symbian.
Now we have the new entrants: Maemo, Android, the iPhone's OS. All based on Unix.
We'd be worried about Microsoft attempting to create an MS-only ghetto that they lock people into
Like .NET?
For most parts, /. seems to be pretty much ignoring what msft is doing these days, as far as server technologies are concerned.
There are several reasons why Google Update runs all the time that you're missing, but the crucial assumption you seem to be making is that the process is "constantly running using up resources".
All of this handwaving is unnecessary, since the problem is "ethical" in a sense. The user does not want to have google updater running for whatever reason => the user should be able to remove it whenever he wants. I suppose the rootkit sony installed back in the day didn't consume too much resources either.
Longer URLs introduce the problem of homophones
Like this?
Please, more comments, or I'll be forced to read the actual article. I don't want to be kicked off slashdot for RtFA...
Try to avoid reading the article, because it's pretty nonsensical. It may be the beer I was drinking, but I didn't really get what they are talking about.
Want to compile a list of companies with Finnish offices and a track record of solid, secure, verifiable e-voting systems with a tangible prototype to impress the decision-gorillas?
Give me 500EUR and I'll hack up such an e-voting system in one workday.
Why on earth is this not a trivial problem?
Anyone knows a good, uptodate, userfriendly and binary distro that still uses KDE3.5?
Debian "Lenny". Though I think I'd recommend staying with 8.04 instead of going to Lenny, having tried both I'd say many things just work better on 8.04.
I honestly didn't know. I've been using Eeebuntu with my 900 series and never actually knew there was a issue with the drivers.
It's probably the problem highlighted here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/337311
There is still new hardware out there that Linux doesn't support out of the box with existing ones? What hardware is that? -- Serious question.
The atheros wlan card on eee pc 900 (how's that for mainstream hardware?).
It has a driver (so theoretically is 'supported out of the box'), but it's just not good enough. The connection through it has intermittent brown-outs and it's slow, whereas the ndiswrapper works fine (nevermind the fact that it's a performance hog).
Just tried with the ubuntu Jaunty beta, and the ath5k driver still has the same problem.
Apart from that, the amount of cluelessness in this whole topic is staggering. Seems like some windows fanboy site referenced this article, and all the winboy trolls came out of the woods immediately.
I've often thought that lots of gaming really is something that could be handled on low-powered devices. Take, for example, X3's trading - you really don't need to have access to the 3d engine to plot trade routes etc. Of course it would still be the same game, as opposed to "gimmicks" like merely sharing a number (amount of money available).
The same goes for item auction houses etc.
Is Python any less about homogenization than Java?
Yes, Python does not have its own GUI toolkit or "look", but rather provides wrappers for whatever native toolkit is used (cocoa, ...).
GNU/FreeBSD. FreeBSD kernel (and libc?) + GNU userland (instead of the BSD userland). There's no linux involved (except perhaps the linux syscall emulation)
So what is the part of the gnu userland that makes it important enough to use in the title of the OS? Compiler?
Given that Ubuntu is down stream from Debian, does this mean that I can run the FreeBSD kernel on my Ubuntu install now?
No, just like you won't have Ubuntu for PA-RISC architecture (even if you have Debian for it).
Dude, you're getting a Nokia!
Or a Nokia
GNOME want to deliver a desktop which is easy to use, which works, which is modeled for users. Therefore the philosophy is more good defaults and less options.
KDE has another philosophy therefore there are more options and switches.
None of this is very relevant for the discussion at hand - this is about rewriting the underlying framework as opposed to polishing the existing one.
Settings & such are to be implemented in individual apps.
This is NOT a troll. What he says is a valid point. Can't you see what happened to KDE.
Yes, it still has bugs. Hardly news on major rewrite.
It's still a troll.
God knows how Red Hat thought they could get away with this. It seems amazingly stupid. And greedy. And stupid.
Maybe being stupid and obvious is the purpose of the whole maneuver.
Ok, so how many (especially desktop) apps will be faster by an amount observable by the user? I still think this wont be many.
Depends how much the apps depend on the file system (both reading and writing). Many desktop apps depend on reading a lot, and they benefit from better ordering of the data in file system.
Of course you only need to care about this if you care about file system performance in the first place - I don't think ext3 is going anywhere soon.
As to the "this seems to be what the doctor ordered for slash drives". Does this imply the number of reads and writes to the drive is reduced?
Yes - if you delay the writes more, you have a better idea what actually needs to hit the disk in the end, so you can cut away unnecessary writes. Since you can also combine several writes, you need to erase fewer blocks (though this one is more speculation than actual knowledge).
.
Lets be realistic, how many applications benefit from this delayed write. Not many is guess.
The guess is wrong.
By delaying writes, ext4 has bigger window to determine how it will allocate stuff.
Also, this seems like just what the doctor ordered for flash drives.
I would rather Firefox developers focusing in making the code more stable and threadable instead of adding unneeded process overhead.
So instead of creating a more robust architecture, squash every little bug in the codebase?
Processes are the most efficient cleanup mechanism around (short of power cycle). This is why operating systems don't come to screeching halt all the time, even if there are tons of bugs in userspace software.
Sadly, processes are underutilized, now that kids think threads/mainloop dispatchers and memory sharing are the way to go. Hopefully Chrome taught them a lesson.
By the third time it gets pathetic, and over used.
I think the whole idea is to be a counterpoint to existing commercials.
Sun's folks created a GPL-incompatible license specifically to have some pieces that Linux doesn't have.
Wrong! The GNU folks created a license that was incompatible with other licenses.
GPL was around, you know, a little bit earlier than CDDL.
The fact that CDDL license is incompatible with Solaris' only relevant competitor seems quite convenient an "accident", whatever people may be saying to you.
Often, the problem with companies is that information doesn't get spread around. People work on their own projects in secret, never bothering to spread their knowledge. Perhaps this will urge some of the those to pay some attention to being useful for other employees as well, as opposed to just getting their own little project done.
Sure, the current build system is a crappy maze of perl scripts but that will change (already has for some people) with the foundation to SBSv2 which is very, very fast and designed to exploit multiple cores.
This is something I've been wondering about - why does it take ages to implement something that could have been done with a bit of SCons tweaking?
A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature.
I think losing that "feature" is a feature in itself.
I'm currently using xfce, and the fact that the session manager thinks it works annoys me quite a bit. I have in fact turned it off, but it still chooses to open a bunch of firefox sessions before wlan is up (and NetworkManager is querying the password in the background).
Another useful "feature" of session management is opening up 17 terminals on bootup. This feature just needs to go. I'm not a big fan of Gnome, but they got this thing right ;-).
Symbian does very well in running on small device. It gives the program features to keep their application using small amounts of systems resources and tries to keep them robust.
Too bad these "features" actually make Symbian heavier than other operating systems. CleanupStack leads to bigger binaries than auto_ptr, you need write of code to do anything related to UI, you need heavyweight client / server architecture for many simple things (lots of context switchs), active objects are much heavier weight (and more error prone) than normal callbacks, ...
The fact is that Symbian's relative success has been mostly due to financial, rather than technical reasons.
And it's not like there has been much choice in the mobile space previously. We've had the simple proprietary OS's of every manufacturer, half-assed locked down linux variants of Motorola, MSFT products and Symbian.
Now we have the new entrants: Maemo, Android, the iPhone's OS. All based on Unix.