You're lucky you didn't start early enough to hit the test kernels that trashed the filesystems, but I think that was back in the 30s. I'm not sure because I didn't start testing until 2.5.69.
Well, it is a beta kernel, so things like that happen. I think the 4GB thing went on for a week. I've been pretty lucky though, I haven't had any panics, though I did with 2.4.18 (something about USB once).
As I understand from watching things on the LKML, 2.6 will support SATA devices through libata. I've noticed every once in awhile, IDE developers are being told not to add SATA support to the drivers and instead that it will be supported by libata (which pretty much spells it out;-). I would suppose this is to get a clean break from the mess (so I've heard) that is the current IDE code.
Yeah, I should have given a better example or qualified the context in which I was using compiling as an example.
Certainly it would make much more sense to use nice rather than change the kernel just for the case of compiling;-)
I was just ranting about how useful nice is, and yet how little use seems to be made of it...
That's probably more true now then ever as more and more people switch from non-*nix systems. Luckily the 2.6 kernel will help hide the error of their ways better than it has in the past...all without an ugly kludge that boosts the priority of the focused window process.
It never ceases to amaze me how many long time users don't realise you can run tasks at lower priorities...
Actually I know about nice... I was using it more to make a point about how much better the scheduler is with the Con's patches. It's a lot easier to start up a compile than it is to duplicate a repeatable situation across a range of machines where the patch makes a difference.
The patches were made to improve interactivety, which means the scheduler tries to guess what processes are interactive (i.e. important to the user), and what processes are CPU hogs (i.e. dnetc, gcc, etc). This allows one to run audio players (i.e. XMMS) without skipping even under a high load (say mozilla churning on some javascript). This is more a patch to help the behavior of tasks that are usually interactive but become cpu hogs and vice verse. So in the case of Mozilla, I don't want it to run niced, but I also want to be able to switch to another window, or type in another window when it hits something that takes a while to process and have my system be responsive. Or maybe even I want to change tabs in Mozilla, that doesn't work so well when my mouse is stuttering across the screen because Mozilla is hogging the cpu.
I haven't booted 2.4 in months so I can't directly compare 2.4 to 2.6, but I can compare the vanilla scheduler without Con's changes to the one containing them. I do know that versus 2.4, this also prevents the need for running X at -10 like some distributions do, which hence reduces the risk that X starts hogging the CPU for some reason and effectively takes down the machine. I can't say I've ever had that happen though;-), but SuSE 8.0 doesn't run X at -10 anyhow.
The 2.4 scheduler is a much different beast than the one in 2.6, though I'm admittedly not clear on what all problems it allegedly solves. I've listed some, but there are other advantages of the changes, you'll need to search the LKML archives for more info.
That probably helps too, but had you tried say test4 and then applied Con's O1 patches, that's one hell of a difference.
With mozilla compiling in the background and vanilla test4, it's very hard to position my mouse pointer accurately on the screen while Mozilla is parsing a new page. Adding Con's patch fixes things to the point that if things didn't take longer to load, I wouldn't even notice that the compile was occurring.
This is on a pretty low-end system though ->K6-2 400 w/384MB
I agree with this, I don't find X to be slow. On the contrary, I've used GNOME 2.0 with a P233 w/64MB using an S3 ViRGE and didn't have any issues. I'm sure Mozilla, or any memory hungry app would be slow, but that's not the fault of the windowing system. Even the system I'm using right now is no speed demon (K6-2 400 w/384MB & ATI AIW 9000 Pro) yet I have no complaints about the speed of X even with multiple tabs open in Mozilla and some misc apps also.
In fact, did anyone else notice that the project homepage only makes one small mention of the fact that the same toolkit ported to frontiers "may be faster"? Unfortunately there's some urban legend that using sockets is somehow crippling the performance of X, which the person that submitted this story used to incite more interest. (I tried to find a benchmark comparing unix domain sockets with a proposed better method, but I came up empty, if this was such a known issue I'd expect benchmarks to be everywhere.)
While I basically agree with this, there are of course some exceptions:
--Network startup (especially involving DHCP)
OK, so there's only one init script where the CPU and disk probably aren't under much load on my system. Otherwise I presume they take as long as they do because the CPU (i.e. hotplug) or the disk (i.e. xfs) is the bottleneck. I'll time how long XP and Linux take to boot and be usable (XP seems to fake this, often explorer takes > 30 seconds to load while enumerating my USB devices if I login right after booting [I think that's what it's doing]).
I'm thinking that parallel loading would benefit an SMT system much more.
Still, how many of us really care? If a desktop user is shutting down their computer while it's not in use wouldn't suspend to disk be a better & faster solution? The only reason I shutdown Linux is to boot into XP or switch kernels (rarely). The only time suspend to disk wouldn't work would be switching kernels or if the system gets corrupted, which are both rare (for me at least;-). I doubt parallel loading would have any effect on a headless Linux proxy I setup for my dad that can boot up and dial out in under 25 seconds (including reiserfs replays). (It would never reboot if I could get my dad to stick it on a UPS.) This isn't a high end system: P233MMX, 64MB FP-RAM, 1.2GB Quantum Fireball, and 430HX chipset.
Even in a server environment, I would think in the case of needing to reboot a machine, the reason it needs to be rebooted (or is rebooting) probably contributes much more to downtime than the period it spends booting.
So basically, in my long-winded post, I see faster booting to be a dubious goal at best. At least on my rather meager system (K6-2 400, 384MB) the gap between being able to use the system on Linux or XP seems pretty slim after I take into account that upon logging into XP, I must wait an additional 15-30 seconds before I can really do useful work. I don't see the length of time it takes to get to the login prompt as a valid comparison since as soon as I see my GNOME desktop, I can start using it, whereas with XP I must wait this additional time. I'll post some hard numbers as soon as 2.6.0-test6-mm2 gets done compiling;-)
Don't ask me, MS hardly makes more sense than SCO;-)
Someone mentioned it could be the easiest patent ever to read, so I looked. That very well may be but does it really need 30 pages of info (perhaps not that long...)? Anyway, I didn't read the entire patent. I got bored after the third paragraph and started skimming.
IIRC the talkback part is closed, which is probably why I'm not seeing it in the Mozilla which I compiled. Still, I thought it gave one an indication on what was being sent to netscape when one clicks to get more information. I would think someone there at MS would be able to identify the crash data...but that might hurt their patent filing so now they have no idea what it does. It's a mystery...a magic piece of software. But then again, MS probably does believe in that -- at least my version of XP magically renders blue screens at the most inopportune times. That usually makes files magically disappear too.
And then there's the TalkBack stuff that's been in Netscape/Mozilla for aeons....
They actually mention that in the patent and claim that Microsoft has no idea what data is sent with that. They also go on to say that what they are patenting is not a system for diagnosing fatal errors such as when netscape crashes, but rather non-fatal errors.
So, anyone ever had Windows report an error that may be causing problems (besides the compatibility warnings which aren't the same thing)?
Some of you have expressed sympathy for SCO employees, but I don't have much. If you're employer is that unscrupulous, it's time to change jobs. Yes, the job market is tight, but not THAT tight.
They might as well prepare. Clearly if the SCO management had any confidence in their claims they wouldn't be selling their stock. I mean, I would think they only stand to gain large amounts of cash if they really believed their claims would hold in court. It's like a magician trying to distract the audience (and it works well, SCO stock was up $0.95 on the news).
So, if you're dumb enough to believe in magic, by all means keep working for SCO...
When it comes down to it, these manager should have asked "Prove that this couldn't be a safety issue". Instead they said to the engineers, "Prove to us that this is a safety issue". It would have been better even if they would have had the attitude "Prove to us that this could be a safety issue", but they didn't even go that far.
This isn't a management position where the worst case is bankrupting the company, this is about people dying. Management attitudes should be adjusted to reflect that FACT.
When the safety board consistently disagrees with the management's decisions, the management should be changed. Instead the safety board was ignored because the head management is the same as the rest. You can't expect the managment that ignored this for years to change, it should be obvious that their attitudes are not appropriate for the job.
What we need is management that does not compromise safety for quantity. Instead the government wants someone who will do as he/she is told and they'll get rid of anyone that doesn't. So really, the question is, how do you change the culture when it's influenced so heavily by a culture besides its own? It must be possible, because the military are some paranoid sonsabitches...
Still, wouldn't it be worth a shot? I mean, you'd pretty much know you would burn up trying to land the shuttle with a hole in the wing.
They say it didn't have enough fuel, but that was as loaded. I don't presume to know much about the shuttle, but surely they could jettison some equipment to reduce the mass. Experiments don't look very important when you know the shuttle is going to disintegrate upon re-entry; they're already gone!
Does anyone know if one of the Soyuz capsules could dock with the shuttle? If not, could they use the EVA to transfer. There are two suits, so it'd take a while to transfer everyone, but I think it'd be possible. Don't they have one at the space station already? I don't think it holds enough people for the crew of seven, but that would allow more time (less people = less consumed) to get another Soyuz or space shuttle up there. Still, that would leave the space station crew without an escape method, but it'd be worth the risk I think. Much safer than landing a space shuttle that we already know is compromised.
Well said. Unless the manager has worked up through the ranks, they seem to get this "better than thou" mentality. Pretty soon instead of listening to the managed, this person simply seems to believe that his/her qualifications are better than those that are managed and just tries to get the group to go along.
Managers seem to forget that they are to coordinate those who know what they are doing, and not presume to know more about the work being done than those who are assigned that task.
Even someone that works his/her way up can fall into this trap, but certainly it is far less likely to occur. In the end, the manager must be a leader but still a member of the team.
True, I was more giving a logical reason why some people would prefer the term flash over RAM in this context. No doubt even they understood it since they were able to reply saying it should be "flash not RAM".
I think everyone would agree that flash is a type of RAM, and the original statement is accurate but lacks a little bit of precision. Though plenty precise, as you say, in this context.
I guess I was just attacking the "Memory" in RAM based on context more than anything. I prefer my nice black & white world of memory and storage where, preferably, they don't mingle (yes, I would prefer to have enough memory that my computer would never have to swap;-).
I always though a hard-drive had pretty random access...
I think flash is more appropriate because it is considered a storage solution in this case rather than a memory solution. So I wouldn't say my hard drive is RAM even though it 1) offers random access and 2) holds data.
Most people, I think, would consider it a storage device. The same goes for the flash devices this MP3 player stores its music on.
I'm not saying that all flash devices are storage, since in some situations they are being used to execute a running program but that is obviously not the case here. It's all based on the context, not some concrete rule that simply takes into account what it can do.
I've heard that they have banner ads showing up on MSN Messenger, so I guess that would help the reasoning to support the Mac.
At the same time, I'm sure they justify (well, externally) the lack of Linux support to insufficient market presence. Going by that logic, the use of their network by Linux users should be insignificant, right?
At first glance this is predictable and understandable. Why would one build a network and let people make money off that network without contributing back? That's pretty much all the GPL asks of those using protected code, abstractly of course:-)
What doesn't really have any justification is locking out all clients. That is unless there is a licensing agreement between Microsoft and Apple which would clear up the reasoning for supporting Macs but not open source platforms like Linux...
But it's very possible that there is a licensing agreement of which I've not been aware. (Then I'd only have one hundred issues with Microsoft rather than one hundred and one.)
Re:Time for a new icon
on
SCO Roundup
·
· Score: 1
Come on, it's not that bad...
It's not like anyone is using the distribution anymore, is it? And if they are, don't they deserve a warning?
Come on, we all know "enterprise" doesn't mean web-servers! The real money is in the cash register market. What kind of business doesn't need a cash register?
Besides, it takes the ability to adapt and evolve to make it in the webserver business. Isn't it better to leverage the state-of-the-art 30 year old code base one spent $5 million on rather than waste time creating new code?
Yeah, I'll believe that "sco.txt" link when SCO releases every last one of those allegedly misappropriated snippets of code to the LKML.
Well, I take that back. I wouldn't be surprised if SCO released that themselves in the hopes that they could catch a OpenSource supporter breaking into their server...
You know you have to watch out for them sneaky commie bastards!
What the hell was their reason for not doing that in the first place?
Let's see:
remote buffer-overflow exploits known in Win95/98 +
abundance of email worms !=
default configuration is no security enabled
I'm no rocket scientist, but I can quickly deduce that an empty administrator password and open ports to a connection created using a "Connect to the internet" dialog is a bad idea.
How many of these machines are home users being infected I wonder? And how less effective would the worm be if even half the machines had these things implemented by default?
Someone should write a worm that infects the vulnerable machine, then finds 2 other vulnerable machines and infects them, or times out. Right before deleting itself, prompt the user whether they are at home or business and log that to a website along with some other info about what IP this came from and how many machines it infected as well as their IPs. Maybe give the user the URL to a patch, but probably better just to leave a little note that we've been here so we can also track how many people just ignore the message and keep going...only to get infected again.
I'm not qualified to determine what constitutes an "ugly hack", so I can't say which is better, KDE or GNOME.
But I can say, KDE takes twice as long to load/unload. On slower machines, that can be a significant amount of time. KDE takes quite a bit more memory to run as well.
That being said, why would I want sensors running in another window sucking up resources when I can just stick xosview always on top on my main desktop and keep a constant eye on things instead of having to switch desktops all the time.
But I guess people want to find a use for all that power that comes with a better CPU.
Slashdot Mirror
You're lucky you didn't start early enough to hit the test kernels that trashed the filesystems, but I think that was back in the 30s. I'm not sure because I didn't start testing until 2.5.69.
Well, it is a beta kernel, so things like that happen. I think the 4GB thing went on for a week. I've been pretty lucky though, I haven't had any panics, though I did with 2.4.18 (something about USB once).
You might want to check out libata.
;-). I would suppose this is to get a clean break from the mess (so I've heard) that is the current IDE code.
As I understand from watching things on the LKML, 2.6 will support SATA devices through libata. I've noticed every once in awhile, IDE developers are being told not to add SATA support to the drivers and instead that it will be supported by libata (which pretty much spells it out
Certainly it would make much more sense to use nice rather than change the kernel just for the case of compiling
That's probably more true now then ever as more and more people switch from non-*nix systems. Luckily the 2.6 kernel will help hide the error of their ways better than it has in the past...all without an ugly kludge that boosts the priority of the focused window process.
The patches were made to improve interactivety, which means the scheduler tries to guess what processes are interactive (i.e. important to the user), and what processes are CPU hogs (i.e. dnetc, gcc, etc). This allows one to run audio players (i.e. XMMS) without skipping even under a high load (say mozilla churning on some javascript). This is more a patch to help the behavior of tasks that are usually interactive but become cpu hogs and vice verse. So in the case of Mozilla, I don't want it to run niced, but I also want to be able to switch to another window, or type in another window when it hits something that takes a while to process and have my system be responsive. Or maybe even I want to change tabs in Mozilla, that doesn't work so well when my mouse is stuttering across the screen because Mozilla is hogging the cpu.
I haven't booted 2.4 in months so I can't directly compare 2.4 to 2.6, but I can compare the vanilla scheduler without Con's changes to the one containing them. I do know that versus 2.4, this also prevents the need for running X at -10 like some distributions do, which hence reduces the risk that X starts hogging the CPU for some reason and effectively takes down the machine. I can't say I've ever had that happen though
The 2.4 scheduler is a much different beast than the one in 2.6, though I'm admittedly not clear on what all problems it allegedly solves. I've listed some, but there are other advantages of the changes, you'll need to search the LKML archives for more info.
That probably helps too, but had you tried say test4 and then applied Con's O1 patches, that's one hell of a difference.
With mozilla compiling in the background and vanilla test4, it's very hard to position my mouse pointer accurately on the screen while Mozilla is parsing a new page. Adding Con's patch fixes things to the point that if things didn't take longer to load, I wouldn't even notice that the compile was occurring.
This is on a pretty low-end system though ->K6-2 400 w/384MB
I agree with this, I don't find X to be slow. On the contrary, I've used GNOME 2.0 with a P233 w/64MB using an S3 ViRGE and didn't have any issues. I'm sure Mozilla, or any memory hungry app would be slow, but that's not the fault of the windowing system. Even the system I'm using right now is no speed demon (K6-2 400 w/384MB & ATI AIW 9000 Pro) yet I have no complaints about the speed of X even with multiple tabs open in Mozilla and some misc apps also.
In fact, did anyone else notice that the project homepage only makes one small mention of the fact that the same toolkit ported to frontiers "may be faster"? Unfortunately there's some urban legend that using sockets is somehow crippling the performance of X, which the person that submitted this story used to incite more interest. (I tried to find a benchmark comparing unix domain sockets with a proposed better method, but I came up empty, if this was such a known issue I'd expect benchmarks to be everywhere.)
While I basically agree with this, there are of course some exceptions:
;-). I doubt parallel loading would have any effect on a headless Linux proxy I setup for my dad that can boot up and dial out in under 25 seconds (including reiserfs replays). (It would never reboot if I could get my dad to stick it on a UPS.) This isn't a high end system: P233MMX, 64MB FP-RAM, 1.2GB Quantum Fireball, and 430HX chipset.
;-)
--Network startup (especially involving DHCP)
OK, so there's only one init script where the CPU and disk probably aren't under much load on my system. Otherwise I presume they take as long as they do because the CPU (i.e. hotplug) or the disk (i.e. xfs) is the bottleneck. I'll time how long XP and Linux take to boot and be usable (XP seems to fake this, often explorer takes > 30 seconds to load while enumerating my USB devices if I login right after booting [I think that's what it's doing]).
I'm thinking that parallel loading would benefit an SMT system much more.
Still, how many of us really care? If a desktop user is shutting down their computer while it's not in use wouldn't suspend to disk be a better & faster solution? The only reason I shutdown Linux is to boot into XP or switch kernels (rarely). The only time suspend to disk wouldn't work would be switching kernels or if the system gets corrupted, which are both rare (for me at least
Even in a server environment, I would think in the case of needing to reboot a machine, the reason it needs to be rebooted (or is rebooting) probably contributes much more to downtime than the period it spends booting.
So basically, in my long-winded post, I see faster booting to be a dubious goal at best. At least on my rather meager system (K6-2 400, 384MB) the gap between being able to use the system on Linux or XP seems pretty slim after I take into account that upon logging into XP, I must wait an additional 15-30 seconds before I can really do useful work. I don't see the length of time it takes to get to the login prompt as a valid comparison since as soon as I see my GNOME desktop, I can start using it, whereas with XP I must wait this additional time. I'll post some hard numbers as soon as 2.6.0-test6-mm2 gets done compiling
Don't ask me, MS hardly makes more sense than SCO ;-)
Someone mentioned it could be the easiest patent ever to read, so I looked. That very well may be but does it really need 30 pages of info (perhaps not that long...)? Anyway, I didn't read the entire patent. I got bored after the third paragraph and started skimming.
IIRC the talkback part is closed, which is probably why I'm not seeing it in the Mozilla which I compiled. Still, I thought it gave one an indication on what was being sent to netscape when one clicks to get more information. I would think someone there at MS would be able to identify the crash data...but that might hurt their patent filing so now they have no idea what it does. It's a mystery...a magic piece of software. But then again, MS probably does believe in that -- at least my version of XP magically renders blue screens at the most inopportune times. That usually makes files magically disappear too.
So, anyone ever had Windows report an error that may be causing problems (besides the compatibility warnings which aren't the same thing)?
So, if you're dumb enough to believe in magic, by all means keep working for SCO...
Agreed.
When it comes down to it, these manager should have asked "Prove that this couldn't be a safety issue". Instead they said to the engineers, "Prove to us that this is a safety issue". It would have been better even if they would have had the attitude "Prove to us that this could be a safety issue", but they didn't even go that far.
This isn't a management position where the worst case is bankrupting the company, this is about people dying. Management attitudes should be adjusted to reflect that FACT.
When the safety board consistently disagrees with the management's decisions, the management should be changed. Instead the safety board was ignored because the head management is the same as the rest. You can't expect the managment that ignored this for years to change, it should be obvious that their attitudes are not appropriate for the job.
What we need is management that does not compromise safety for quantity. Instead the government wants someone who will do as he/she is told and they'll get rid of anyone that doesn't. So really, the question is, how do you change the culture when it's influenced so heavily by a culture besides its own? It must be possible, because the military are some paranoid sonsabitches...
Still, wouldn't it be worth a shot? I mean, you'd pretty much know you would burn up trying to land the shuttle with a hole in the wing.
They say it didn't have enough fuel, but that was as loaded. I don't presume to know much about the shuttle, but surely they could jettison some equipment to reduce the mass. Experiments don't look very important when you know the shuttle is going to disintegrate upon re-entry; they're already gone!
Does anyone know if one of the Soyuz capsules could dock with the shuttle? If not, could they use the EVA to transfer. There are two suits, so it'd take a while to transfer everyone, but I think it'd be possible. Don't they have one at the space station already? I don't think it holds enough people for the crew of seven, but that would allow more time (less people = less consumed) to get another Soyuz or space shuttle up there. Still, that would leave the space station crew without an escape method, but it'd be worth the risk I think. Much safer than landing a space shuttle that we already know is compromised.
Well said. Unless the manager has worked up through the ranks, they seem to get this "better than thou" mentality. Pretty soon instead of listening to the managed, this person simply seems to believe that his/her qualifications are better than those that are managed and just tries to get the group to go along.
Managers seem to forget that they are to coordinate those who know what they are doing, and not presume to know more about the work being done than those who are assigned that task.
Even someone that works his/her way up can fall into this trap, but certainly it is far less likely to occur. In the end, the manager must be a leader but still a member of the team.
Ah, but we could have ASCII porn!
True, I was more giving a logical reason why some people would prefer the term flash over RAM in this context. No doubt even they understood it since they were able to reply saying it should be "flash not RAM".
;-).
I think everyone would agree that flash is a type of RAM, and the original statement is accurate but lacks a little bit of precision. Though plenty precise, as you say, in this context.
I guess I was just attacking the "Memory" in RAM based on context more than anything. I prefer my nice black & white world of memory and storage where, preferably, they don't mingle (yes, I would prefer to have enough memory that my computer would never have to swap
But mostly, just playing devil's advocate...
I always though a hard-drive had pretty random access...
I think flash is more appropriate because it is considered a storage solution in this case rather than a memory solution. So I wouldn't say my hard drive is RAM even though it 1) offers random access and 2) holds data.
Most people, I think, would consider it a storage device. The same goes for the flash devices this MP3 player stores its music on.
I'm not saying that all flash devices are storage, since in some situations they are being used to execute a running program but that is obviously not the case here. It's all based on the context, not some concrete rule that simply takes into account what it can do.
Well, that's what I mean. Strange that there is a version for Macs, but no version for Linux.
;-) Somewhat inconsistent maybe is a better term.
Not really strange, we know why that is
I've heard that they have banner ads showing up on MSN Messenger, so I guess that would help the reasoning to support the Mac.
At the same time, I'm sure they justify (well, externally) the lack of Linux support to insufficient market presence. Going by that logic, the use of their network by Linux users should be insignificant, right?
At first glance this is predictable and understandable. Why would one build a network and let people make money off that network without contributing back? That's pretty much all the GPL asks of those using protected code, abstractly of course :-)
What doesn't really have any justification is locking out all clients. That is unless there is a licensing agreement between Microsoft and Apple which would clear up the reasoning for supporting Macs but not open source platforms like Linux...
But it's very possible that there is a licensing agreement of which I've not been aware.
(Then I'd only have one hundred issues with Microsoft rather than one hundred and one.)
Come on, it's not that bad...
It's not like anyone is using the distribution anymore, is it? And if they are, don't they deserve a warning?
McBride, what the hell are you doing on /.?!!
Come on, we all know "enterprise" doesn't mean web-servers! The real money is in the cash register market. What kind of business doesn't need a cash register?
Besides, it takes the ability to adapt and evolve to make it in the webserver business. Isn't it better to leverage the state-of-the-art 30 year old code base one spent $5 million on rather than waste time creating new code?
Yeah, I'll believe that "sco.txt" link when SCO releases every last one of those allegedly misappropriated snippets of code to the LKML.
Well, I take that back. I wouldn't be surprised if SCO released that themselves in the hopes that they could catch a OpenSource supporter breaking into their server...
You know you have to watch out for them sneaky commie bastards!
Let's see:
I'm no rocket scientist, but I can quickly deduce that an empty administrator password and open ports to a connection created using a "Connect to the internet" dialog is a bad idea.
How many of these machines are home users being infected I wonder? And how less effective would the worm be if even half the machines had these things implemented by default?
Someone should write a worm that infects the vulnerable machine, then finds 2 other vulnerable machines and infects them, or times out. Right before deleting itself, prompt the user whether they are at home or business and log that to a website along with some other info about what IP this came from and how many machines it infected as well as their IPs. Maybe give the user the URL to a patch, but probably better just to leave a little note that we've been here so we can also track how many people just ignore the message and keep going...only to get infected again.
That's legitimate research, isn't it?
So, who's willing to fund my research?
I'm not qualified to determine what constitutes an "ugly hack", so I can't say which is better, KDE or GNOME.
But I can say, KDE takes twice as long to load/unload. On slower machines, that can be a significant amount of time. KDE takes quite a bit more memory to run as well.
That being said, why would I want sensors running in another window sucking up resources when I can just stick xosview always on top on my main desktop and keep a constant eye on things instead of having to switch desktops all the time.
But I guess people want to find a use for all that power that comes with a better CPU.