It's a nicer approach, though. The X server doesn't need to be a part of the kernel, which makes things safer and simpler. And it can be not installed or replaced.
Besides, context switches are pretty fast on Linux anyway, and I don't see why communication couldn't be optimized to minimize the amount of context switching needed.
One thing I do wish is that the kernel was what handled all the graphics. Then the X server wouldn't need to run as root and do strange things with hardware, which IMHO is a task best left to the kernel.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 3, Informative
Right. But you need to do this marshalling one way or another. Remove network transparency and you'd *still* have to provide data in some particular format and follow some particular protocol.
My point is that just getting rid of the network socket won't help you any. You'll still end sending exactly the same stuff but using another mechanism, incurring in pretty much the same overhead.
It's not like getting rid of the socket would suddenly free you from the need of communicating in some standard way with the server. How would it understand you otherwise?
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 5, Informative
Plugged in how?
This is something I spent a *long* time explaining to some people on a forum about a related subject. Network transparency doesn't involve significant overhead, dammit!
There has to be some way for an application to talk to X. So, you remove the network protocol, how do you want to talk it to X then, magic? In order for two different programs to talk to each other there has to be some kind of protocol, no way around it.
Now, networking indeed can slow things down a little due to things like latency. But that's effectively inexistent if you're talking on the local host. And X already has shared memory communication as well. On Linux there are also the so called Unix Sockets, which is pretty much like TCP/IP, only with even less overhead since it's done locally, so it can be implemented in a simpler way.
However, as far as an application is concerned, an Unix socket and a TCP/IP one are exactly the same thing, so it makes no sense to get rid of network transparency - you wouldn't win anything with that anyway.
The motherboard supports generating an interrupt when something happens. You can tell it to do that in case of a corrected error, uncorrected error, or never. I think Windows will BSOD when that happens, so I'd just set it to do it on an uncorrectable error. Then it will crash, but at least it will stop things before they mess up something important.
On Linux you have the ecc-linux(2.4) and bluesmoke(2.6) kernel patches, which will give you a file in/proc you can monitor with detailed statistics about how many errors were corrected. IIRC, without specific support Linux will generate an oops, but continue if the board generates an interrupt. The patches can be told what to do in that case.
I suppose there must be some software to get all the features on Windows too, but I don't know where to get it.
Sure it's more expensive, but it's great. If the computer does something strange I know that I can check/proc/ram or/proc/mc/0, see the statistics and instantly find if the memory is seeing errors or not. Here I do see a corrected error or two sometimes, although very infrequently. But it's indeed very nice to know it's been corrected.
However, even if it's ECC I still wouldn't like at all knowing that it's not been tested. ECC has limits to the corrections it can make, after all.
Bah, I don't play FPSes *because* all there is these days is deathmatch in one form or another.
If it's pure deathmatch, then it's just general free for all madness, which makes me bored fairly quickly. Team play is often not a lot better.
Now finishing Quake 1 in cooperative mode was one of the most fun times I had. You can actually plan things out, discuss some kind of strategy, decide who gets the ammo/goes first, provide help, protect a team mate, etc, that is, it can actually involve THOUGHT, instead of just shooting whatever happens to be nearby.
I've seen one system running the beta of Russian version of Win2K less than a year ago. Completely infested with spyware and other crap, of course.
This was one of the most "interesting" cleaning jobs I had, because I couldn't wipe it out. It *had* to be the Russian version, and I couldn't get it anywhere (in Spain), legal or not.
Interestingly enough, it worked fairly well after being cleaned up, and all the MS updates including Service Pack 4 installed just fine on it. I wonder how much of beta code remains after so many updates. The "beta" text on the desktop did remain after I was done with it.
My general recommendation for anybody else who has to deal with anything like this: refuse, no matter how much they beg, or how many personal favours you owe them.
The GPL crowd drives some people away. Some Microsoft fans draw me away. Apple fans drive other people away. So what? Everybody is attracted and repelled by one thing or another.
IMHO, proprietary software is not a solution, it's sometimes a necessary compromise when there's no other alternative. In that sense it works well for vertical applications. For nearly everything else, I'd say it's a big disadvantage since usually you get stuck with a single vendor and lock-in.
If I understand it correctly, it works like this. When a company is about to go to court, they realize that the GPL is the only thing that gives them the permission to distribute the code. If they try to argue that the GPL doesn't apply, then they suddenly have nothing in their favour at all and are clearly guilty of copyright infringement.
No wonder it never went to court, because it's clearly an unwinnable situation.
I still don't get where's the need to declare Point objects when just passing the coordinates would have been a bit shorter to type, but now I do see it's not nearly as bad as it looks:-)
The antivirus probably doesn't add much to the I/O load, though.
If it's an antivirus that scans things you're running, then the antivirus would scan the.EXE you just tried to start started, reading it from disk, and give the OS the permission to continue. Now it would be in the disk cache, which is where the OS would get it from to run the program.
I'd say the problem with antiviruses would be that they're not necessarily paralellizable. If things go like this:
1. User clicks on program 2. Antivirus scans.EXE 3. Program runs
Then there's nothing to paralellize there, since the program won't run until the scan is done.
Speed-wise, my PentiumM 1600 laptop is about even with it, when using one CPU. Shows that at last Intel managed to come up with a decent processor.
However, the Athlon is a lot more responsive. You can easily play video, compile things and burn a CD at 24x at the same time. Another thing that improves is stability.
A few years ago there was an evil bug in artsd that made it choke on some MP3 I had. Processor usage rises to 100% and system becomes unusable, since artsd runs with realtime scheduling. It does move on after a while, but meanwhile all you can do is go get a cup of coffee.
On the Athlon the same bug causes CPU use go to 100% on one CPU. The other one works perfectly well, and the system remains perfectly responsive, so I can ignore it, or bring up the task manager and kill it.
Yet another advantage is that you now have a whole CPU you can waste. So running antiviruses, really pretty screensavers and things like that doesn't make the impact they do on a single CPU system.
If that's how Microsoft codes, I'm not surprised at all at the huge memory requirements. Take a look at the end of the source listing, in the Draw3DBorder function.
I don't get what is the point of creating Point objects if they are going to be thrown right away. Especially since DrawLine is overloaded and admits coordinates without using any Point objects! And that code will probably make the memory usage rise fairly quickly, until GC kicks in and gets rid of it.
I strongly suspect mine contributed to the demise of my old CRT, as she spent almost the whole day on top of it, and quite a lot of fur seemed to have got inside.
On the other hand, now I have a nice 19" LCD, and it was really hilarious to watch her as she tried to climb on the LCD and figure out what happened with it. She spent several days walking around the monitor maybe hoping it would go back to the old comfortable thing;-)
Grandparent is just yet another guy who can't seem to understand the concept of 'lots of different people post on slashdot'. You know, some people want everything to be tiny, others want everything to be GPLd, etc. Of course if you put all of that together you get insane requirements.
That would be because on paper DPI is what is important.
The amount of pixels that fit on an A4 sheet of paper depend not only on the DPI but also on the margins. So the amount of pixels would be a somewhat confusing measure.
On the other hand, for monitors, DPI is not very important. A game may specify a minimum resolution of 800x600 because at 640x480 the interface won't fully fit on the screen or be unreadable, and that happens regardless of DPI.
Sarge is kind of fine, except it doesn't get security updates fast enough. But yeah, I suppose it could work. But that's not what I was talking about anyway.
As far as I can see, the usefulness of the stable distribution dropped drastically. Right now I only consider it for one thing - firewalls, which include things like DNS servers and such. Its usefulness as a server with some big service such as http, smtp, imap, etc is very limited.
I already explained that yes, I can get backports, or use packages from newer releases, or compile from source. But all those are very unattractive solutions for reasons I already explained. They're unreliable, unsafe or unpractical.
Take getting packages from testing, for instance. Why the heck does that have to require me to install a testing version of libc? Is that really because exim uses features added to libc during the last month, or because it's the version testing includes? This often results in pulling 30 packages from testing that include most of the base, and which sometimes create problems during upgrades.
The rest of your post isn't even relevant to what I was saying. Yeah, I can administrate a Debian system. No, I don't want to do more work than strictly necessary.
It's hard to set up a reasonable modern server with Debian. For example, a mail server. With Debian stable you get:
ancient exim ancient spamassassin no clamav etc.
The problem with that is that you go online and see lots of nice setups explained you simply can't do with the provided version, because it relies on packages a year old, and what's provided by Debian is much older.
Sure, there are solutions. Mixed stable/testing, backports, building your own. But all of those suck.
Mixed systems and ones with unofficial sources are error prone. Once in a while something screws up, and you suddenly find that the mail server that was supposed to be just upgraded for a security fix wasn't fully installed, and dpkg won't remove the package... and you're stuck with no mail server until you find a way of fixing it. Sure, at work you should have a test server, but this happened to me at home and it's annoying as heck.
backports have the additional problem of that you have to trust the site, and that's rather difficult.
Building your own seems like the best one in comparison, but can also be awfully problematic due to outdated development packages. Ideally you need more than one computer with Debian so that you avoid installing gcc on the server. And if I'm going to build from source I'd rather use Gentoo on the server, where things compile from source wonderfully well.
There are several Office suites in existence that can read MS word files. You could say that it is "license cracking" too as well, since KWord, OpenOffice and some other programs make it unnecessary for me to pay for an MS Office license. I bet MS is not very happy with that.
Yet this is *perfectly fine*. The vendor's happiness or unhappiness about the situation is something that's completely irrelevant, and I'll state here very clearly that I don't care in the slightest if Larry McVoy, MS or somebody else goes bankrupt. It's *their* job to figure how to earn money.
There's no law against reverse engineering in most sane countries, and definitely no law that makes it obligatory to maintain somebody else's way of earning money.
AFAIK, there's no fundamental right to earn money. If Larry isn't getting money from it, well, tough. MS isn't getting any money from Samba either, and that doesn't make it any less legitimate.
I have nothing against Larry releasing a free version, but doing that still doesn't give him any right to profit. I certainly have nothing against him having retired it, but retiring licenses to people vaguely associated with people doing reverse engineering is plain stupid.
1. BitKeeper is a technically good program 2. Larry McVoy is an arrogant a******. 3. I have absolutely no problem with Tridge
Sure, Larry might not like people cloning his program. Well, tough. A clone is what is needed for interoperability. Sure, the Samba team could probably have built their own networking protocol, probably even a better one, but that wasn't the point!
For example, at a small company they're installing a biometric thingy to keep track of when people enter and exit. It looks like the biometric sensor will be used as a replacement of the username, and still require a password.
Now, using it for something seriously important, such as ATMs is definitely a very bad idea.
Yup, actually I have, I wrote a little module for it. Nothing very impressive though.
Now, the architecture is certainly debatable. PAM is essentially a library that replaces the code that would have inside the program itself instead. In that sense it's a massive improvement.
Now, a replacement in the form of a daemon would be interesting. I wonder if there is anything like that out there. Especially something PAM compatible, if possible.
Slashdot Mirror
It's a nicer approach, though. The X server doesn't need to be a part of the kernel, which makes things safer and simpler. And it can be not installed or replaced.
Besides, context switches are pretty fast on Linux anyway, and I don't see why communication couldn't be optimized to minimize the amount of context switching needed.
One thing I do wish is that the kernel was what handled all the graphics. Then the X server wouldn't need to run as root and do strange things with hardware, which IMHO is a task best left to the kernel.
Right. But you need to do this marshalling one way or another. Remove network transparency and you'd *still* have to provide data in some particular format and follow some particular protocol.
My point is that just getting rid of the network socket won't help you any. You'll still end sending exactly the same stuff but using another mechanism, incurring in pretty much the same overhead.
It's not like getting rid of the socket would suddenly free you from the need of communicating in some standard way with the server. How would it understand you otherwise?
Plugged in how?
This is something I spent a *long* time explaining to some people on a forum about a related subject. Network transparency doesn't involve significant overhead, dammit!
There has to be some way for an application to talk to X. So, you remove the network protocol, how do you want to talk it to X then, magic? In order for two different programs to talk to each other there has to be some kind of protocol, no way around it.
Now, networking indeed can slow things down a little due to things like latency. But that's effectively inexistent if you're talking on the local host. And X already has shared memory communication as well. On Linux there are also the so called Unix Sockets, which is pretty much like TCP/IP, only with even less overhead since it's done locally, so it can be implemented in a simpler way.
However, as far as an application is concerned, an Unix socket and a TCP/IP one are exactly the same thing, so it makes no sense to get rid of network transparency - you wouldn't win anything with that anyway.
The motherboard supports generating an interrupt when something happens. You can tell it to do that in case of a corrected error, uncorrected error, or never. I think Windows will BSOD when that happens, so I'd just set it to do it on an uncorrectable error. Then it will crash, but at least it will stop things before they mess up something important.
/proc you can monitor with detailed statistics about how many errors were corrected. IIRC, without specific support Linux will generate an oops, but continue if the board generates an interrupt. The patches can be told what to do in that case.
On Linux you have the ecc-linux(2.4) and bluesmoke(2.6) kernel patches, which will give you a file in
I suppose there must be some software to get all the features on Windows too, but I don't know where to get it.
I just buy ECC RAM.
/proc/ram or /proc/mc/0, see the statistics and instantly find if the memory is seeing errors or not. Here I do see a corrected error or two sometimes, although very infrequently. But it's indeed very nice to know it's been corrected.
Sure it's more expensive, but it's great. If the computer does something strange I know that I can check
However, even if it's ECC I still wouldn't like at all knowing that it's not been tested. ECC has limits to the corrections it can make, after all.
Bah, I don't play FPSes *because* all there is these days is deathmatch in one form or another.
If it's pure deathmatch, then it's just general free for all madness, which makes me bored fairly quickly. Team play is often not a lot better.
Now finishing Quake 1 in cooperative mode was one of the most fun times I had. You can actually plan things out, discuss some kind of strategy, decide who gets the ammo/goes first, provide help, protect a team mate, etc, that is, it can actually involve THOUGHT, instead of just shooting whatever happens to be nearby.
Quite likely.
I've seen one system running the beta of Russian version of Win2K less than a year ago. Completely infested with spyware and other crap, of course.
This was one of the most "interesting" cleaning jobs I had, because I couldn't wipe it out. It *had* to be the Russian version, and I couldn't get it anywhere (in Spain), legal or not.
Interestingly enough, it worked fairly well after being cleaned up, and all the MS updates including Service Pack 4 installed just fine on it. I wonder how much of beta code remains after so many updates. The "beta" text on the desktop did remain after I was done with it.
My general recommendation for anybody else who has to deal with anything like this: refuse, no matter how much they beg, or how many personal favours you owe them.
I don't see the point.
The GPL crowd drives some people away. Some Microsoft fans draw me away. Apple fans drive other people away. So what? Everybody is attracted and repelled by one thing or another.
IMHO, proprietary software is not a solution, it's sometimes a necessary compromise when there's no other alternative. In that sense it works well for vertical applications. For nearly everything else, I'd say it's a big disadvantage since usually you get stuck with a single vendor and lock-in.
None is needed, as the other post says.
If I understand it correctly, it works like this. When a company is about to go to court, they realize that the GPL is the only thing that gives them the permission to distribute the code. If they try to argue that the GPL doesn't apply, then they suddenly have nothing in their favour at all and are clearly guilty of copyright infringement.
No wonder it never went to court, because it's clearly an unwinnable situation.
Aah, makes a lot more sense now!
:-)
I still don't get where's the need to declare Point objects when just passing the coordinates would have been a bit shorter to type, but now I do see it's not nearly as bad as it looks
The antivirus probably doesn't add much to the I/O load, though.
.EXE you just tried to start started, reading it from disk, and give the OS the permission to continue. Now it would be in the disk cache, which is where the OS would get it from to run the program.
.EXE
If it's an antivirus that scans things you're running, then the antivirus would scan the
I'd say the problem with antiviruses would be that they're not necessarily paralellizable. If things go like this:
1. User clicks on program
2. Antivirus scans
3. Program runs
Then there's nothing to paralellize there, since the program won't run until the scan is done.
Dual is really a lot smoother.
Here I've got a Dual Athlon MP 2000+
Speed-wise, my PentiumM 1600 laptop is about even with it, when using one CPU. Shows that at last Intel managed to come up with a decent processor.
However, the Athlon is a lot more responsive. You can easily play video, compile things and burn a CD at 24x at the same time. Another thing that improves is stability.
A few years ago there was an evil bug in artsd that made it choke on some MP3 I had. Processor usage rises to 100% and system becomes unusable, since artsd runs with realtime scheduling. It does move on after a while, but meanwhile all you can do is go get a cup of coffee.
On the Athlon the same bug causes CPU use go to 100% on one CPU. The other one works perfectly well, and the system remains perfectly responsive, so I can ignore it, or bring up the task manager and kill it.
Yet another advantage is that you now have a whole CPU you can waste. So running antiviruses, really pretty screensavers and things like that doesn't make the impact they do on a single CPU system.
I've recently started looking at .NET, as a replacement for VB6. Tried it a bit myself, and ended coming up with this page:
k b; EN-US;323116
http://support.microsoft.com/default.aspx?scid=
If that's how Microsoft codes, I'm not surprised at all at the huge memory requirements. Take a look at the end of the source listing, in the Draw3DBorder function.
I don't get what is the point of creating Point objects if they are going to be thrown right away. Especially since DrawLine is overloaded and admits coordinates without using any Point objects! And that code will probably make the memory usage rise fairly quickly, until GC kicks in and gets rid of it.
Hehe, evil cats.
;-)
I strongly suspect mine contributed to the demise of my old CRT, as she spent almost the whole day on top of it, and quite a lot of fur seemed to have got inside.
On the other hand, now I have a nice 19" LCD, and it was really hilarious to watch her as she tried to climb on the LCD and figure out what happened with it. She spent several days walking around the monitor maybe hoping it would go back to the old comfortable thing
Um, I'm a russian hacker and I'm offended by the implication that there's anything wrong with it.
Bah, what modpoints?
Grandparent is just yet another guy who can't seem to understand the concept of 'lots of different people post on slashdot'. You know, some people want everything to be tiny, others want everything to be GPLd, etc. Of course if you put all of that together you get insane requirements.
That would be because on paper DPI is what is important.
The amount of pixels that fit on an A4 sheet of paper depend not only on the DPI but also on the margins. So the amount of pixels would be a somewhat confusing measure.
On the other hand, for monitors, DPI is not very important. A game may specify a minimum resolution of 800x600 because at 640x480 the interface won't fully fit on the screen or be unreadable, and that happens regardless of DPI.
Sarge is kind of fine, except it doesn't get security updates fast enough. But yeah, I suppose it could work. But that's not what I was talking about anyway.
As far as I can see, the usefulness of the stable distribution dropped drastically. Right now I only consider it for one thing - firewalls, which include things like DNS servers and such. Its usefulness as a server with some big service such as http, smtp, imap, etc is very limited.
I already explained that yes, I can get backports, or use packages from newer releases, or compile from source. But all those are very unattractive solutions for reasons I already explained. They're unreliable, unsafe or unpractical.
Take getting packages from testing, for instance. Why the heck does that have to require me to install a testing version of libc? Is that really because exim uses features added to libc during the last month, or because it's the version testing includes? This often results in pulling 30 packages from testing that include most of the base, and which sometimes create problems during upgrades.
The rest of your post isn't even relevant to what I was saying. Yeah, I can administrate a Debian system. No, I don't want to do more work than strictly necessary.
Because it's not stable, it's fossilized.
It's hard to set up a reasonable modern server with Debian. For example, a mail server. With Debian stable you get:
ancient exim
ancient spamassassin
no clamav
etc.
The problem with that is that you go online and see lots of nice setups explained you simply can't do with the provided version, because it relies on packages a year old, and what's provided by Debian is much older.
Sure, there are solutions. Mixed stable/testing, backports, building your own. But all of those suck.
Mixed systems and ones with unofficial sources are error prone. Once in a while something screws up, and you suddenly find that the mail server that was supposed to be just upgraded for a security fix wasn't fully installed, and dpkg won't remove the package... and you're stuck with no mail server until you find a way of fixing it. Sure, at work you should have a test server, but this happened to me at home and it's annoying as heck.
backports have the additional problem of that you have to trust the site, and that's rather difficult.
Building your own seems like the best one in comparison, but can also be awfully problematic due to outdated development packages. Ideally you need more than one computer with Debian so that you avoid installing gcc on the server. And if I'm going to build from source I'd rather use Gentoo on the server, where things compile from source wonderfully well.
Huh, so what?
There are several Office suites in existence that can read MS word files. You could say that it is "license cracking" too as well, since KWord, OpenOffice and some other programs make it unnecessary for me to pay for an MS Office license. I bet MS is not very happy with that.
Yet this is *perfectly fine*. The vendor's happiness or unhappiness about the situation is something that's completely irrelevant, and I'll state here very clearly that I don't care in the slightest if Larry McVoy, MS or somebody else goes bankrupt. It's *their* job to figure how to earn money.
There's no law against reverse engineering in most sane countries, and definitely no law that makes it obligatory to maintain somebody else's way of earning money.
AFAIK, there's no fundamental right to earn money. If Larry isn't getting money from it, well, tough. MS isn't getting any money from Samba either, and that doesn't make it any less legitimate.
I have nothing against Larry releasing a free version, but doing that still doesn't give him any right to profit. I certainly have nothing against him having retired it, but retiring licenses to people vaguely associated with people doing reverse engineering is plain stupid.
What I've got from this so far is this:
1. BitKeeper is a technically good program
2. Larry McVoy is an arrogant a******.
3. I have absolutely no problem with Tridge
Sure, Larry might not like people cloning his program. Well, tough. A clone is what is needed for interoperability. Sure, the Samba team could probably have built their own networking protocol, probably even a better one, but that wasn't the point!
But only when not used for anything important.
For example, at a small company they're installing a biometric thingy to keep track of when people enter and exit. It looks like the biometric sensor will be used as a replacement of the username, and still require a password.
Now, using it for something seriously important, such as ATMs is definitely a very bad idea.
Yup, actually I have, I wrote a little module for it. Nothing very impressive though.
Now, the architecture is certainly debatable. PAM is essentially a library that replaces the code that would have inside the program itself instead. In that sense it's a massive improvement.
Now, a replacement in the form of a daemon would be interesting. I wonder if there is anything like that out there. Especially something PAM compatible, if possible.
I hope you're joking. There's no need for Linux client for that monstrosity.
I've tried it myself and it's far, FAR worse than anything else. CVS is wonderful in comparison.