Breeder reactors can do much to alleviate the pileup of un-usable radioactive byproducts...they can use non-uranium materials and if you put the right fuel in them to begin with, they'll create further fissionable material. Infact, i once read long ago that a breeder type reactor produces enough "waste product" after 10 years of operation to start fueling an additional power plant.
Indeed this is probably the case. However, did it ever occur to you just what breeder reactors produce as fuel? Yes, you're quite right, plutonium, Pu-239. Lots of it, and high quality. And do you know which fissile material it is easiest to make nuclear weapons out of? Yes, correct again, Plutonium-239. It's a whole lot easier to separate the main contaminant of Pu-239 (Pu-240) than it is to separate Uranium-235 from U-238, and concentrations of Pu-239 in plutonium from breeder reactors is typically around 99% - plenty pure enough to build a weapon from. Compare that to Uranium, where typical commercial reactors require 2-4.5% pure U-235 (and the waste has a lower concentration of that), but weapons-grade Uranium is around 80% U-235.
Now, given the relative ease with which governments (and possibly terrorists too, but who knows for sure?) have got hold of Uranium for their weapons-building programs, some of which was weapons-grade from the existing nuclear powers, but most of which was orginally destined for commercial reactors, do you really then want to give them the opportunity to much more easily get hold of weapons-grade plutonium from commercial breeder reactors?
Supporting breeder reactors, no matter how noble your intentions, is tantamount to supporting nuclear proliferation. Do you really want that? Do you think the world would be safer if everyone had nukes?
The
Free Qt Foundation is an organisation dedicated to keeping Qt free and alive no matter what happens to Trolltech. Indeed, the agreement between Trolltech and the Free Qt Foundation specifically states that if Trolltech ever go under or stop development of Qt, then Qt will automatically be released under the BSD License - and you can't get much freer than that.
Nice try, but fortunately for KDE (and us), somebody thought of this (and fixed the problem) a long long time before you did.
The Real Time Scheduler does not really make Linux an RTOS because in and of itself it does not provide kernel pre-emption - the ability for the kernel to interrupt kernel-space code to deal with incoming events that _must_ be processed. This is a requirement of a 'proper' hard-RTOS because such an OS must be able to guarantee a response time, and if it cannot interrupt kernel code the OS scheduler may be stuck waiting for kernel code to return before it can go on to deal with the input. The rtsched patches do appear to integrate with MontaVista's kernel pre-emption patches however, and together they would indeed form a proper hard real-time OS.
Kernel pre-emption does not come without a price though - it can make a significant dent in overall performance, and it is tricky to implement in a clean way, and this is why kernel pre-emption will probably stay out of the mainstream kernel for the forseeable future. It also isn't necessary for 99.9% of people, who, as long as the latency, the time to respond, is on average less than a few ms, are happy. This is called 'soft' real-time and is more than adequate for any video or audio work.
Linux is actually pretty bad at soft real-time as standard, with typical latencies around the 100ms mark, which is rather worse than any version of Windows 9x or NT, and a lot lot worse than BeOS, which has latencies in the sub-5ms realm. Andrew Morton's Low-Latency patches deal with this quite nicely, taking typical latencies down to the 1.5ms mark by improving various kernel algorithms and adding a few points where the kernel can reschedule itself during long periods in kernel-space code. This represents the best latency in just about any OS that does not do hard real-time with kernel pre-emption (QNX, vxWorks etc.) and does not hit performance in the way that pre-emption patches do.
What would be very interesting is to combine the low-latency patch with the improved scheduler in the rtsched patches...
As for GetRewted patches... well, I'm not entirely convinced about the value of a non-executable stack. The problem is whether they actually do any useful good - they give a warm fuzzy feeling of security while only actually preventing a limited subset of attacks. In addition, it's in the wrong place. It's a kernel-space fix for what is really a user-space problem - and certainly I think it's better to fix problems at source than patch them up elsewhere - otherwise you end up with code spaghetti.
My own personal favourite anti-stack-smashing add-on is libsafe, originally a Bell Labs project, which overrides dangerous libc functions with its own, safe functions, either by using the LD_PRELOAD feature of ELF shared objects to protect existing binaries, or by being linked in to a binary at compile time, preferentially to the existing libc functions. In addition, version 2 of libsafe now includes protection against format-string attacks that appear to be the new scourge of unix. Of course, the best place for this protection is in libc itself, and glibc 2.2 does include some protection like this, but it is a compile-time option only, and further, is primarily designed to help developers fix overflows during program testing rather than helping sysadmins in the wild - it causes more of a performance hit than libsafe does.
Anyway - as for 2.4.5, nice to see the VM is sorting itself out - I was that close to turning my desktop machine's ext2 partitions into UFS. I think I might convert them to ReiserFS now.:)
Starbucks is tasteless slop, and US instant is the worst in the world - it's just about undrinkable. Meanwhile, smaller coffee shops that were the last bastions of good coffee shut down all the time, unable to compete against the economies of scale of the larger coffee corporations.
I don't see this happening much in Europe. The big multinational coffee corporations are present doing their dirty work but they have never achieved the same level of mindshare penetration, and consequently there are fewer outlets and they are less busy. The traditional small coffee shop or cafe still has a chance in Europe, and as well you can even buy drinkable (i.e. it doesn't feel like Draino trickling down your throat) and decently caffeinated instant coffee in the supermarket.
I am firmly of the belief that this is the primary reason why KDE (a primarily European-developed environment) is advancing faster than GNOME (a primarily American-developed environment). It is simple. KDE developers get better coffee!
So don't laugh about NASA funding satellites to watch coffee grow - it is vital to the development of Free Software in the US!
Red Hat may have dropped their SPARC support but there's still plenty to choose from:
Debian has active ports for both SPARC/UltraSPARC with a 32-bit userland and an UltraSPARC port with a 64-bit userland. The 32-bit SPARC port is much more up-to-date and complete, and basically is at parity with Debian-x86. It has a stable, testing and unstable branch just like Debian-x86 and thanks to the clever Debian package management and development tools is kept up-to-date with the main x86 tree automatically. Due to Debian's widely-ported and volunteer nature the SPARC port is likely to be supported for quite some time.
SuSE is also widely ported, and again, has a SPARC port which is essentially at parity with the main x86 version - 7.1.
Slackware also has a SPARC port, but if you are used to Red Hat or Solaris it may be too much of a culture shock with things like its BSD-style initscripts and primitive package management.
All of these are modern, up-to-date distros, which (Debian especially) I prefer to Red Hat.
I find predictive text input very handy indeed, and very fast too - I get about 20 wpm which, while slow compared to typing on a normal qwerty keyboard (about a quarter my normal typing speed) is still much much faster than the traditional phone text input. I can write a full-length 160-character text message in about 2 minutes, and need not use confusing abbreviations. It even gets the sentence capitalisation right automatically.:)
Admittedly, it does take a bit of getting used to - it took me about 10 messages before I really got the hang of it, but then... how long did it take you to learn to type efficiently?
One other thing to watch out for is the specific implementation of predictive text input - I find the Motorola version substantially better than the implementation on Nokias, as it provides a list of its best predictions in a line at the bottom of the screen that can be selected using the left/right or up/down keys, and it also automatically learns new words rather than having to manually add them to the dictionary.
Procfs represents data as text because again, that is the UNIX way. There are two things that are basically unique to UNIX systems, and they are that, in userland, everything is a file, and that plain text is a universal data format. Procfs adheres to this, sysctl does not.
You misunderstand the AGP files in/proc - those are control and information files (which belong in/proc), not the device interfaces. The actual device read/write interfaces are, as you'd expect, in/dev -/dev/agpgart on my Linux box. That's not strange at all.
The format (and location) of the data does change in/proc from time to time, yes, but not that often. In any case, sysctl has a similar problem - kernel interfaces do change, and the changes in the kernel are reflected in the sysctl interface. In fact, I'd argue that the fact that procfs forces a conversion to plain text makes it _more_ likely that the data format will stay the same, as it adds a layer of abstraction that sysctl does not.
As for cross-platform issues, tell me, does your/etc/sysctl.conf work flawlessly across FreeBSD, NetBSD, OpenBSD and BSDI? I thought not, and that's even though they originate from the same codebase.
And to your most relevant point, that binary to text conversion is slow and memory intensive. Well, this would be a problem if procfs was a real in-memory filesystem... but it isn't. The data inside/proc is not actually generated from the kernel until the relevant file is open()'ed. So, the/proc tree takes precisely zero extra processor time and zero extra memory until you read or write something to it.
Are there any other arguments for sysctl and against procfs? It still seems like a case of favouring tradition over a superior design.
In order to read data from a device in/dev you need the same system calls, open(), read() and close(). If you use a non-UNIX system, it usually only requires one call to do the same thing, usually along the lines of device_read().
UNIX already makes an ease-of-use/speed trade-off for/dev, I don't see why that should be any different for kernel config. Speed is not really much of an issue when controlling kernel parameters in any case, whilst it certainly is for reading/writing data from device drivers.
From a consistency point of view, it's illogical. From a speed point of view, the difference is small and essentially irrelevant. I can only see one good reason why the BSD's don't use a/proc, and that's not-invented-here syndrome.
Are there any other advantages to using sysctl over/proc, besides speed (not really significant)? It just doesn't make sense to me.
It's because it's much more sensible and true to the UNIX philosophy than sysctl is (everything is a file), and I wish more people would use it, if just to convince the xBSD developers to support it in addition to the traditional sysctl framework.
Linux supports both, and developers choose to use/proc rather than sysctl because it is, to them, a superior interface. I have to agree with this, using file I/O is a whole pile easier and unix-like than mucking around with sysctl.
There's no reason why any of the BSD's can't support it other than developer inertia, and for the BSD traditionalists, it doesn't have to be the primary kernel config interface, merely a compatibility option. However, believe me, once/proc support is in there, it will quickly become popular. It just works better!
I have got the lucent one on my thinkpad here. They only have a binary driver which only works for 2.2.1[234].
Now for me to be able to use both internet and 2.4.1, I actually have to ipmasq via a windoze box at home...
That's not true any more, although I'm somewhat unsure of the legality of it, as it doesn't appear that the original ltmodem source code was officially released by Lucent but rather leaked by a third party with source access...
Anyway, if you have a Lucent winmodem, check out
http://walbran.org/sean/linux/stodolsk/ where a fully working open-source driver based on the original Lucent driver is available. It has numerous bugfixes compared to the original Lucent binary-only release, and compiles cleanly for both 2.2 and 2.4 kernels.
What is true is that the developers of the new Linux GUI are making the same crappy mistakes as Windoze, in that they are not improving the CLI at the same time. Why doesn't KDE provide a "launch" command that takes a list of arguments and does exactly the same thing as the user clicking on those icons?
Actually, it does. Next time you're in a Konsole in KDE, type 'kfmclient exec $filename' where $filename is, surprisingly, the name of the data file. This will use KDE's file types to automatically launch the correct application for dealing with this data file.
As a side note, I believe Windows has the same capabilities in its command line - the rather unceremoniously-named 'start' command.
Aaah yes, the old shared memory transport thing in X. It's not the panacea you make it out to be - far from being inefficient, unix domain sockets are actually not significantly slower than a shared memory transport in a modern PC system. In Linux at least, the unix domain socket code is some of the most heavily hand-optimized code there is - it just doesn't get any faster.
As for an SHM transport never having been implemented in XFree86, no, it has, but the improvement in speed was so negligible that it is not compiled in by default.
Check out Precision Insight's paper on a shared-memory transport in XFree86 and please would everybody stop moaning about how crap XFree86 is - it isn't. BTW your alpha channels and font anti-aliasing are coming soon:p
Your logic is flawed: just because the US may not be the worst does not mean to say that the original poster's comment wasn't entirely valid. If your view of the world is based on the idea that things that are not the worst cannot be bad, then there is more wrong with the US educational system than I thought:)
Let's work through this (flawed) logic, but instead of the concepts invloved here, let's replace them with... ooh, say, a comparison of normal and low-tar cigarettes. Normal cigarettes are worse for your health than low-tar cigarettes. By your logic, because low-tar cigarettes are not the worst type of cigarette for you, then they aren't harmful. Cancer, emphysema and heart disease statistics would tend to disagree with this logic.
I won't get into playing my-country-is-better-than-yours. Neither of us have an objective opinion on this, and as a UK citizen who's lived in the US I find your comments both arrogant and rude, especially as you give no explanation as to why you feel this.
If you don't feel comfortable with other US citizens airing the country's dirty laundry then... well, perhaps you should fix the problem rather than trying to hide it.
PS: I'd be happy to mod you down if I had moderator points, not because I disagree with what you say (I do), but because your argument is flawed and stupid.
Given the increasingly wide availability of broadband, and the fact that Linux has such a solid firewall built-in in the forms of ipchains and especially the forthcoming iptables in 2.4...
Why not offer to auto-setup a basic firewall during the 'workstation' install?
This would be massively helpful to the many newbie Linux users, handy for those of us with not much time on our hands, and would be a great boost to the reputation of the distro as secure-by-default. It is, after all, not that difficult for a setup program to simply deny all incoming SYNs on all external interfaces, but is beyond many who are new to Linux.
Given that those of us who would find this a problem are also probably those who are confident enough to mess with ipchains/iptables anyway, I can't see how this could be a disadvantage.
So, Red Hat, Mandrake, Debian et al.... how about it?
Much as I hate to say this in a story all about NS6 and Mozilla... but this tallies very well indeed with my experience.
The most recent nightly of moz I have (29/9/2000)is still slow, not anywhere near as slow as it once was - it is actually very usable, but it is still noticably slower than other browsers, especially in the UI. Click on a menu or any other XPCOM widget and you can feel the thing thinking about it before something happens. Those of you with fast machines may not notice this, but it's very noticable on my old PII. Page rendering is decently fast, but not anywhere near best-of-the-best.
There are still rendering bugs - there's a small but annoying one here on/. where the rounded left edge of the green story headings is not placed correctly. Mysteriously, this bug seems to disappear after about an hour's use of mozilla. What's going on there then?
Perhaps most worrying is the bloat. On launch, mozilla is already quite greedy, taking up around 18MB on my machine. However, an hour's solid web-surfing - in just one browser window - has this up to about 40MB, which is just insane. On my 64MB machine, this causes no end of swapping and thrash. I pity those poor souls trying to get mozilla working on machines with anything less.
Now, before you flame me to death (or, of course, mod me down into oblivion) for attacking mozilla, remember that (with the exception of bloat, which appears to be getting worse:( these are huge improvements over the moz we knew and loved of just a month or two ago, and the stated aim from now until M20 is to improve all these things, and these have started to bear fruit already.
However, there is a new kid on the block if you want a fast, solid, modern, compatible browser for *nix, and that's Konqueror. As it stands now, for pretty much every aspect of web-browsing I can think of, it's significantly better than moz is. It's blazingly fast (neck and neck with Opera IMHO), solidly standards-compliant (it claims HTML4/CSS2 compatibility, and I haven't seen anything which implies otherwise yet), has a small memory footprint, does Java, Javascript and SSL well... what more could you want?
Finally there is a browser for *nix that I want to use. It feels good.
No, sorry - I disagree. What he's going on about is having style guidelines - and sticking to them, which, for the most part, most X apps do not, whatever toolkit or desktop environment they are written for.
KDE _already_ has style guidelines (and I'm sure GNOME probably does as well) - but getting apps written to follow those guidelines is unsexy and something I think most free software authors don't care for that much.
What XMLGUI does is it frees the author from having to think that hard about it - simply by using it in your app to create an interface, that interface becomes KDE styleguide-compliant.
The fact that it's customizable is, whilst cool and potentially useful, irrelevant to this article...
Please forgive me if I get a few details wrong, I'm not a KDE developer, I've just read the presentations and seen what happens in the KDE 2 betas... but
KDE 2's XMLGUI technology is doing this now.
What it allows is, as the name suggests, developers to create XML descriptions of the UI rather than rigid, fixed programmatic representations. At run-time, these descriptions are merged with the standard KDE interface elements (also described in XML) and then created on-screen using the standard QT/KDE widgets.
The net effect of this is that simply by using this technology, you can create a customizable, dynamic GUI that _automatically_ conforms to the KDE2 style guidelines, and all by just writing a few lines of XML...
What I'm surprised no-one seems to have thought of so far in the discussion is this:
Steganographic data transmission by network traffic patterns
Imagine, if you will, a web server in, let's say, China, that has a peculiarity about the way it responds to incoming connections. When an incoming connection is accepted, the ACK in the TCP SYN/ACK sequence is delayed by a certain amount. Delays above a certain threshold code a 1, delays below that threshold code a 0. Hey presto, you have a well-hidden (albeit low-bandwidth) communications channel. The client (outside the country) continues to request files (thus making new connections) until it has recieved all the data, and a CRC is used to make sure that this somewhat unreliable method of data transmission has succeeded.
Of course, this has its problems - the net does not guarantee delivery times, and such a scheme could be defeated by large random delays being introduced at the infamous 'Great Firewall of China'.
However, having now introduced the concept, some of you can probably think of ways to do it which take time out of the equation.
Imagine a web browser which, on a certain page, requested the images on the page in a certain order, and that order coded for some value (binary coding would be _most_ inefficient here.) The webserver (outside of the country, of course) notes this order and logs the data for decryption. There you go, another well-hidden (but low-bandwidth) channel.
Or how about encoding data in TCP header options?
There are so many ways to encode data in a well-hidden way on the net it's untrue, and due to the extremely erratic nature and enormous volume of IP traffic, is almost impossible to detect.
IIRC some of the DDoS tools use patterns of ICMP and UDP packets as ways of messaging, discarding any actual data contained within the packets... so yes, it's been done before.
Sorry folks, but encoding stuff in the low bits of data files just isn't subtle enough...:)
Slashdot Mirror
Breeder reactors can do much to alleviate the pileup of un-usable radioactive byproducts...they can use non-uranium materials and if you put the right fuel in them to begin with, they'll create further fissionable material. Infact, i once read long ago that a breeder type reactor produces enough "waste product" after 10 years of operation to start fueling an additional power plant.
Indeed this is probably the case. However, did it ever occur to you just what breeder reactors produce as fuel? Yes, you're quite right, plutonium, Pu-239. Lots of it, and high quality. And do you know which fissile material it is easiest to make nuclear weapons out of? Yes, correct again, Plutonium-239. It's a whole lot easier to separate the main contaminant of Pu-239 (Pu-240) than it is to separate Uranium-235 from U-238, and concentrations of Pu-239 in plutonium from breeder reactors is typically around 99% - plenty pure enough to build a weapon from. Compare that to Uranium, where typical commercial reactors require 2-4.5% pure U-235 (and the waste has a lower concentration of that), but weapons-grade Uranium is around 80% U-235.
Now, given the relative ease with which governments (and possibly terrorists too, but who knows for sure?) have got hold of Uranium for their weapons-building programs, some of which was weapons-grade from the existing nuclear powers, but most of which was orginally destined for commercial reactors, do you really then want to give them the opportunity to much more easily get hold of weapons-grade plutonium from commercial breeder reactors?
Supporting breeder reactors, no matter how noble your intentions, is tantamount to supporting nuclear proliferation. Do you really want that? Do you think the world would be safer if everyone had nukes?
The Free Qt Foundation is an organisation dedicated to keeping Qt free and alive no matter what happens to Trolltech. Indeed, the agreement between Trolltech and the Free Qt Foundation specifically states that if Trolltech ever go under or stop development of Qt, then Qt will automatically be released under the BSD License - and you can't get much freer than that.
Nice try, but fortunately for KDE (and us), somebody thought of this (and fixed the problem) a long long time before you did.
The Real Time Scheduler does not really make Linux an RTOS because in and of itself it does not provide kernel pre-emption - the ability for the kernel to interrupt kernel-space code to deal with incoming events that _must_ be processed. This is a requirement of a 'proper' hard-RTOS because such an OS must be able to guarantee a response time, and if it cannot interrupt kernel code the OS scheduler may be stuck waiting for kernel code to return before it can go on to deal with the input. The rtsched patches do appear to integrate with MontaVista's kernel pre-emption patches however, and together they would indeed form a proper hard real-time OS.
Kernel pre-emption does not come without a price though - it can make a significant dent in overall performance, and it is tricky to implement in a clean way, and this is why kernel pre-emption will probably stay out of the mainstream kernel for the forseeable future. It also isn't necessary for 99.9% of people, who, as long as the latency, the time to respond, is on average less than a few ms, are happy. This is called 'soft' real-time and is more than adequate for any video or audio work.
Linux is actually pretty bad at soft real-time as standard, with typical latencies around the 100ms mark, which is rather worse than any version of Windows 9x or NT, and a lot lot worse than BeOS, which has latencies in the sub-5ms realm. Andrew Morton's Low-Latency patches deal with this quite nicely, taking typical latencies down to the 1.5ms mark by improving various kernel algorithms and adding a few points where the kernel can reschedule itself during long periods in kernel-space code. This represents the best latency in just about any OS that does not do hard real-time with kernel pre-emption (QNX, vxWorks etc.) and does not hit performance in the way that pre-emption patches do.
What would be very interesting is to combine the low-latency patch with the improved scheduler in the rtsched patches...
As for GetRewted patches... well, I'm not entirely convinced about the value of a non-executable stack. The problem is whether they actually do any useful good - they give a warm fuzzy feeling of security while only actually preventing a limited subset of attacks. In addition, it's in the wrong place. It's a kernel-space fix for what is really a user-space problem - and certainly I think it's better to fix problems at source than patch them up elsewhere - otherwise you end up with code spaghetti.
My own personal favourite anti-stack-smashing add-on is libsafe, originally a Bell Labs project, which overrides dangerous libc functions with its own, safe functions, either by using the LD_PRELOAD feature of ELF shared objects to protect existing binaries, or by being linked in to a binary at compile time, preferentially to the existing libc functions. In addition, version 2 of libsafe now includes protection against format-string attacks that appear to be the new scourge of unix. Of course, the best place for this protection is in libc itself, and glibc 2.2 does include some protection like this, but it is a compile-time option only, and further, is primarily designed to help developers fix overflows during program testing rather than helping sysadmins in the wild - it causes more of a performance hit than libsafe does.
Anyway - as for 2.4.5, nice to see the VM is sorting itself out - I was that close to turning my desktop machine's ext2 partitions into UFS. I think I might convert them to ReiserFS now. :)
Seriously, what is up with US coffee?
Starbucks is tasteless slop, and US instant is the worst in the world - it's just about undrinkable. Meanwhile, smaller coffee shops that were the last bastions of good coffee shut down all the time, unable to compete against the economies of scale of the larger coffee corporations.
I don't see this happening much in Europe. The big multinational coffee corporations are present doing their dirty work but they have never achieved the same level of mindshare penetration, and consequently there are fewer outlets and they are less busy. The traditional small coffee shop or cafe still has a chance in Europe, and as well you can even buy drinkable (i.e. it doesn't feel like Draino trickling down your throat) and decently caffeinated instant coffee in the supermarket.
I am firmly of the belief that this is the primary reason why KDE (a primarily European-developed environment) is advancing faster than GNOME (a primarily American-developed environment). It is simple. KDE developers get better coffee!
So don't laugh about NASA funding satellites to watch coffee grow - it is vital to the development of Free Software in the US!
Red Hat may have dropped their SPARC support but there's still plenty to choose from:
Debian has active ports for both SPARC/UltraSPARC with a 32-bit userland and an UltraSPARC port with a 64-bit userland. The 32-bit SPARC port is much more up-to-date and complete, and basically is at parity with Debian-x86. It has a stable, testing and unstable branch just like Debian-x86 and thanks to the clever Debian package management and development tools is kept up-to-date with the main x86 tree automatically. Due to Debian's widely-ported and volunteer nature the SPARC port is likely to be supported for quite some time.
SuSE is also widely ported, and again, has a SPARC port which is essentially at parity with the main x86 version - 7.1.
Slackware also has a SPARC port, but if you are used to Red Hat or Solaris it may be too much of a culture shock with things like its BSD-style initscripts and primitive package management.
All of these are modern, up-to-date distros, which (Debian especially) I prefer to Red Hat.
Try them out. You might like them.
I find predictive text input very handy indeed, and very fast too - I get about 20 wpm which, while slow compared to typing on a normal qwerty keyboard (about a quarter my normal typing speed) is still much much faster than the traditional phone text input. I can write a full-length 160-character text message in about 2 minutes, and need not use confusing abbreviations. It even gets the sentence capitalisation right automatically. :)
Admittedly, it does take a bit of getting used to - it took me about 10 messages before I really got the hang of it, but then... how long did it take you to learn to type efficiently?
One other thing to watch out for is the specific implementation of predictive text input - I find the Motorola version substantially better than the implementation on Nokias, as it provides a list of its best predictions in a line at the bottom of the screen that can be selected using the left/right or up/down keys, and it also automatically learns new words rather than having to manually add them to the dictionary.
Procfs represents data as text because again, that is the UNIX way. There are two things that are basically unique to UNIX systems, and they are that, in userland, everything is a file, and that plain text is a universal data format. Procfs adheres to this, sysctl does not.
/proc - those are control and information files (which belong in /proc), not the device interfaces. The actual device read/write interfaces are, as you'd expect, in /dev - /dev/agpgart on my Linux box. That's not strange at all.
/proc from time to time, yes, but not that often. In any case, sysctl has a similar problem - kernel interfaces do change, and the changes in the kernel are reflected in the sysctl interface. In fact, I'd argue that the fact that procfs forces a conversion to plain text makes it _more_ likely that the data format will stay the same, as it adds a layer of abstraction that sysctl does not.
/etc/sysctl.conf work flawlessly across FreeBSD, NetBSD, OpenBSD and BSDI? I thought not, and that's even though they originate from the same codebase.
/proc is not actually generated from the kernel until the relevant file is open()'ed. So, the /proc tree takes precisely zero extra processor time and zero extra memory until you read or write something to it.
You misunderstand the AGP files in
The format (and location) of the data does change in
As for cross-platform issues, tell me, does your
And to your most relevant point, that binary to text conversion is slow and memory intensive. Well, this would be a problem if procfs was a real in-memory filesystem... but it isn't. The data inside
Are there any other arguments for sysctl and against procfs? It still seems like a case of favouring tradition over a superior design.
That's not the point. :)
/dev you need the same system calls, open(), read() and close(). If you use a non-UNIX system, it usually only requires one call to do the same thing, usually along the lines of device_read().
/dev, I don't see why that should be any different for kernel config. Speed is not really much of an issue when controlling kernel parameters in any case, whilst it certainly is for reading/writing data from device drivers.
/proc, and that's not-invented-here syndrome.
/proc, besides speed (not really significant)? It just doesn't make sense to me.
In order to read data from a device in
UNIX already makes an ease-of-use/speed trade-off for
From a consistency point of view, it's illogical. From a speed point of view, the difference is small and essentially irrelevant. I can only see one good reason why the BSD's don't use a
Are there any other advantages to using sysctl over
It's because it's much more sensible and true to the UNIX philosophy than sysctl is (everything is a file), and I wish more people would use it, if just to convince the xBSD developers to support it in addition to the traditional sysctl framework.
/proc rather than sysctl because it is, to them, a superior interface. I have to agree with this, using file I/O is a whole pile easier and unix-like than mucking around with sysctl.
/proc support is in there, it will quickly become popular. It just works better!
Linux supports both, and developers choose to use
There's no reason why any of the BSD's can't support it other than developer inertia, and for the BSD traditionalists, it doesn't have to be the primary kernel config interface, merely a compatibility option. However, believe me, once
I have got the lucent one on my thinkpad here. They only have a binary driver which only works for 2.2.1[234]. Now for me to be able to use both internet and 2.4.1, I actually have to ipmasq via a windoze box at home...
That's not true any more, although I'm somewhat unsure of the legality of it, as it doesn't appear that the original ltmodem source code was officially released by Lucent but rather leaked by a third party with source access...
Anyway, if you have a Lucent winmodem, check out http://walbran.org/sean/linux/stodolsk/ where a fully working open-source driver based on the original Lucent driver is available. It has numerous bugfixes compared to the original Lucent binary-only release, and compiles cleanly for both 2.2 and 2.4 kernels.
What is true is that the developers of the new Linux GUI are making the same crappy mistakes as Windoze, in that they are not improving the CLI at the same time. Why doesn't KDE provide a "launch" command that takes a list of arguments and does exactly the same thing as the user clicking on those icons?
:-)
Actually, it does. Next time you're in a Konsole in KDE, type 'kfmclient exec $filename' where $filename is, surprisingly, the name of the data file. This will use KDE's file types to automatically launch the correct application for dealing with this data file.
As a side note, I believe Windows has the same capabilities in its command line - the rather unceremoniously-named 'start' command.
Next time try looking harder before you bash.
Aaah yes, the old shared memory transport thing in X. It's not the panacea you make it out to be - far from being inefficient, unix domain sockets are actually not significantly slower than a shared memory transport in a modern PC system. In Linux at least, the unix domain socket code is some of the most heavily hand-optimized code there is - it just doesn't get any faster.
:p
As for an SHM transport never having been implemented in XFree86, no, it has, but the improvement in speed was so negligible that it is not compiled in by default.
Check out Precision Insight's paper on a shared-memory transport in XFree86 and please would everybody stop moaning about how crap XFree86 is - it isn't. BTW your alpha channels and font anti-aliasing are coming soon
This is a strawman argument.
:)
:)
Your logic is flawed: just because the US may not be the worst does not mean to say that the original poster's comment wasn't entirely valid. If your view of the world is based on the idea that things that are not the worst cannot be bad, then there is more wrong with the US educational system than I thought
Let's work through this (flawed) logic, but instead of the concepts invloved here, let's replace them with... ooh, say, a comparison of normal and low-tar cigarettes. Normal cigarettes are worse for your health than low-tar cigarettes. By your logic, because low-tar cigarettes are not the worst type of cigarette for you, then they aren't harmful. Cancer, emphysema and heart disease statistics would tend to disagree with this logic.
I won't get into playing my-country-is-better-than-yours. Neither of us have an objective opinion on this, and as a UK citizen who's lived in the US I find your comments both arrogant and rude, especially as you give no explanation as to why you feel this.
If you don't feel comfortable with other US citizens airing the country's dirty laundry then... well, perhaps you should fix the problem rather than trying to hide it.
PS: I'd be happy to mod you down if I had moderator points, not because I disagree with what you say (I do), but because your argument is flawed and stupid.
PPS: If you're a troll, you're a very good one
Given the increasingly wide availability of broadband, and the fact that Linux has such a solid firewall built-in in the forms of ipchains and especially the forthcoming iptables in 2.4...
Why not offer to auto-setup a basic firewall during the 'workstation' install?
This would be massively helpful to the many newbie Linux users, handy for those of us with not much time on our hands, and would be a great boost to the reputation of the distro as secure-by-default. It is, after all, not that difficult for a setup program to simply deny all incoming SYNs on all external interfaces, but is beyond many who are new to Linux.
Given that those of us who would find this a problem are also probably those who are confident enough to mess with ipchains/iptables anyway, I can't see how this could be a disadvantage.
So, Red Hat, Mandrake, Debian et al.... how about it?
Much as I hate to say this in a story all about NS6 and Mozilla... but this tallies very well indeed with my experience.
/. where the rounded left edge of the green story headings is not placed correctly. Mysteriously, this bug seems to disappear after about an hour's use of mozilla. What's going on there then?
:( these are huge improvements over the moz we knew and loved of just a month or two ago, and the stated aim from now until M20 is to improve all these things, and these have started to bear fruit already.
The most recent nightly of moz I have (29/9/2000)is still slow, not anywhere near as slow as it once was - it is actually very usable, but it is still noticably slower than other browsers, especially in the UI. Click on a menu or any other XPCOM widget and you can feel the thing thinking about it before something happens. Those of you with fast machines may not notice this, but it's very noticable on my old PII. Page rendering is decently fast, but not anywhere near best-of-the-best.
There are still rendering bugs - there's a small but annoying one here on
Perhaps most worrying is the bloat. On launch, mozilla is already quite greedy, taking up around 18MB on my machine. However, an hour's solid web-surfing - in just one browser window - has this up to about 40MB, which is just insane. On my 64MB machine, this causes no end of swapping and thrash. I pity those poor souls trying to get mozilla working on machines with anything less.
Now, before you flame me to death (or, of course, mod me down into oblivion) for attacking mozilla, remember that (with the exception of bloat, which appears to be getting worse
However, there is a new kid on the block if you want a fast, solid, modern, compatible browser for *nix, and that's Konqueror. As it stands now, for pretty much every aspect of web-browsing I can think of, it's significantly better than moz is. It's blazingly fast (neck and neck with Opera IMHO), solidly standards-compliant (it claims HTML4/CSS2 compatibility, and I haven't seen anything which implies otherwise yet), has a small memory footprint, does Java, Javascript and SSL well... what more could you want?
Finally there is a browser for *nix that I want to use. It feels good.
No, sorry - I disagree. What he's going on about is having style guidelines - and sticking to them, which, for the most part, most X apps do not, whatever toolkit or desktop environment they are written for.
KDE _already_ has style guidelines (and I'm sure GNOME probably does as well) - but getting apps written to follow those guidelines is unsexy and something I think most free software authors don't care for that much.
What XMLGUI does is it frees the author from having to think that hard about it - simply by using it in your app to create an interface, that interface becomes KDE styleguide-compliant.
The fact that it's customizable is, whilst cool and potentially useful, irrelevant to this article...
Please forgive me if I get a few details wrong, I'm not a KDE developer, I've just read the presentations and seen what happens in the KDE 2 betas... but
:-)
KDE 2's XMLGUI technology is doing this now.
What it allows is, as the name suggests, developers to create XML descriptions of the UI rather than rigid, fixed programmatic representations. At run-time, these descriptions are merged with the standard KDE interface elements (also described in XML) and then created on-screen using the standard QT/KDE widgets.
The net effect of this is that simply by using this technology, you can create a customizable, dynamic GUI that _automatically_ conforms to the KDE2 style guidelines, and all by just writing a few lines of XML...
I think this is very very neat indeed
What I'm surprised no-one seems to have thought of so far in the discussion is this:
:)
Steganographic data transmission by network traffic patterns
Imagine, if you will, a web server in, let's say, China, that has a peculiarity about the way it responds to incoming connections. When an incoming connection is accepted, the ACK in the TCP SYN/ACK sequence is delayed by a certain amount. Delays above a certain threshold code a 1, delays below that threshold code a 0. Hey presto, you have a well-hidden (albeit low-bandwidth) communications channel. The client (outside the country) continues to request files (thus making new connections) until it has recieved all the data, and a CRC is used to make sure that this somewhat unreliable method of data transmission has succeeded.
Of course, this has its problems - the net does not guarantee delivery times, and such a scheme could be defeated by large random delays being introduced at the infamous 'Great Firewall of China'.
However, having now introduced the concept, some of you can probably think of ways to do it which take time out of the equation.
Imagine a web browser which, on a certain page, requested the images on the page in a certain order, and that order coded for some value (binary coding would be _most_ inefficient here.) The webserver (outside of the country, of course) notes this order and logs the data for decryption.
There you go, another well-hidden (but low-bandwidth) channel.
Or how about encoding data in TCP header options?
There are so many ways to encode data in a well-hidden way on the net it's untrue, and due to the extremely erratic nature and enormous volume of IP traffic, is almost impossible to detect.
IIRC some of the DDoS tools use patterns of ICMP and UDP packets as ways of messaging, discarding any actual data contained within the packets... so yes, it's been done before.
Sorry folks, but encoding stuff in the low bits of data files just isn't subtle enough...