One thing I can't figure out is how, if your flashed LinuxBIOS is broken, how you can even necessarily boot back to FreeDOS to flash your BIOS again back to the vendor's BIOS. I'm not one of those fortunates with a BIOS-in-ROM that I can revert to by just closing a jumper...
Basically, you can't. If you don't have a recovery jumper, then flashing with a linux BIOS that doesn't work on your system is a one-way ticket.
In fact, even with the jumper you will most likely be hosed. In the two or three designs that I know about, all the jumper does is cause the OEM BIOS to restore the default settings. It doesn't change the actual BIOS code. So, if you replace the original BIOS with something totally different, I wouldn't expect the jumper to do anything at all.
The bottom line is, don't reflash unless you have a reason and have confidence that the new BIOS will at least boot DOS or some operating system that will let you flash back to the last known good version.
The biggest power hog on an intel board is the CPU, followed by the northbridge (memory and pci part of the chipset).
Built-in accessories such as fibre-channel and/or gigabit ethernet currently also consume significant power.
Sometimes the power supply circuitry gets a bit hot as well, but only when it has to deliver ridiculous ammounts of current to a power-hog chip.
For example, current pentium mobile chip power supplies are supposed to be designed for upwards of 20 amps. This is at the core voltage, which varies depending on the speed-step state. IIRC the low setting is 1.15 V, and the higher setting is around 1.5 V or so. The maximum current case occurs at the higher voltage.
It's hard to pass 20 amps through a transistor or current sensing resistor or inductor without a little heat getting generated. You end up using 5 or 6 big transistors for the swithcing, and one or two big inductors, and very low resistance current sensing resistors. And you have to make the copper traces really wide, and use extra vias. To tell the truth, it's kind of a PITA. And if you, the engineer, screw up, the whole thing could catch on fire or fail in some other spectacular way.
I'm not 100% sure that's true. Rockets are only aerodynamically stable, if at all, above some certain speed. It sounds as though this one may never have reached that speed, and much of the electronics seems to have failed very early on.
The guy, whatever his name is, seems to specifically allude to the rocket being stable because he says that in the event of an IMU failure, the main engine can continue to fire provided that the rocket is in the air and on an upward trajectory.
I wasn't able to watch the video, but I did read the post that reproduced the failure analysis.
Most of the sensible complaints I hear about it seem to be coming from people who want features that aren't there yet, or who feel the performance isn't up to snuff.
But seriously, with the exceptoin of bugs, there arn't any other complaints you can have about any piece of software.
Well, that's partly my point. X is not a piece of software. Xfree86 is a piece of software, but it isn't the only Xserver in the world. So, if someone complains that it is too slow, or that it is too hard to configure, then that is a sensible complaint generated by that person's response to a particular piece of software.
But, if someone says Xfree86 is too hard to configure, therefore we need to abandon Xwindows and completely change the fundamental way we do graphics on linux, then I would say, whoa, let's make sure we are making a good decision here!
Furthermore, a lot of people seem to think that window managers, desktop programs, and even widget sets are all somehow part of X. They say "X sucks" and then they rant and rave about stuff which is not directly related to the Xwindows system.
I have posted this basic idea too many times now under this article, so I don't want to go into it any more now. If you are really interested, check out my other posts.
I don't know much about genetic algorithms and such, but I am aware of GAUL, a c-language based genetic algorithm library that is available on sourceforge.
Someday I'll have to look more deeply into these things, since the basic idea intrigues me.
In that case, you should be trying to convince your favorite game developers to develop picoGUI (or whatever) versions of the game.
Also, I think that when you say "X" you are really talking about Xfree86, no?
Also, also, it sounds like there is no reason for you to use linux, so I'm not sure why you even care about this thread. Just stick to windows, if it makes you happy.
The reason to use gcj and libswt is to have have binaries that are easy to execute, instead of.java files that require a jvm. My idea is to fit java programs into the existing standard distribution mode of most open and free software where you do./configure, make, make install.
Personally I like java, but I don't like dealing with a jvm. And I think that from the perspective of a developer trying to gain acceptance for his or her free software project, the jvm burden is significant. On the other hand, if the distro comes with gcj, users can (eventually) just do./configure, make, and make install to install libswt, and then programs which use it can do the same. This allows a sun-free, and 100% free software solution to the java problem.
Perhaps it is a wrong-headed approach. It is certainly heresy from the perspective of the Sun orthodoxy. But getting away from non-free jvm's is a good thing, in my opinion.
You have hit upon what sounds like a genuine criticism of X.
If the members of the vast horde of X critics were as knowledgeable on the topic of X as you appear to be, I would not defend X.
I just get tired of all the people saying "we need to get rid of Xwindows because XFree86 is too hard to configure" or "Xwindows is so slow, just look at how long it takes to change directories in Nautilus" or something like that.
I didn't realize that PicoGUI was intended to be network transparent. I did look at the page, but then I saw that they only had about 70 functions in their API, and weren't actually claiming to be a replacement for X in the first place. So I left.
Maybe we should all just use SWT and java (compiled with gcj). Then we would have a fast native implementation that is easy to port from one platform to another.
There's nothing specific to X apart from the 'culture' generated from years of coding with current methods, and this kind of culture is sometimes harder to work past than any technical difficulties.
With an entirely new system, the chance for an easier break is there. [emphasis added]
I guess I basically agree.
Although, I just use linux because I like all the geeky stuff it can do and for philisophical reasons related to free software.
I don't mind not having a consistent look and feel across apps. I am not a linux evangelist, though. I don't try to convince people that they should switch, and I don't really care if people switch. I just want there to be enough people using it that it continues to be viable.
Blame the clunkiness of the linux desktop on the linux desktop, not on X (in general) or Xfree86 in particular.
There are a lot of concepts associated with X on linux. X, in the form of Xfree86, is at the bottom. Then on top of that there is a widget toolkit (i.e., gtk+ or athena or motif).
Interacting with X is the window manager, which may use a widget toolkit, and which excercises control over placement, size and other characteristics of application windows. Each of these application windows gets to decide how the pixels it has control over should look, within the limitations of the display device. And, in many cases, these applications are built on top of a widget toolkit which may or may not be the same as the one used for the window manager. Then there is the "desktop" which is really just another application.
So, you see, "X" is probably not the cause of the clunkiness you perceive.
On the other hand, if Xfree86 is genuinely too slow, then you should build (or clamor for the building of) a faster x-server.
But don't throw out the whole concept of the x-server, for it gives us many benefits, perhaps most importantly, network transparency.
And, by the way, most people are not saying "Why change? X is ubiquitous!" They are either saying, "it will never happen: X is ubiquitous" or they are saying "Don't change it, because there isn't a superior alternative yet."
I, on the other hand, am saying "don't blame X for problems which lie elsewhere." And, perhaps, "don't put forth an opinion on X if you don't really know what it is."
Oh, and, "the PicoAPI has something like 70 functions in it. Let's not get carried away!"
You may be right about the benefits of having a consistent look-and-feel.
But this has nothing to do with X. X is a low-level, display server technology. It has nothing to do with look-and-feel.
There is no reason related to X itself that we cannot have a consistent look and feel. All it would take is a concensus on the part of new developers. Also, if people are interested, they can always update some old classics (such as xv and gv) to use new widget sets. I have no idea how hard this would be, but I'm pretty sure it is too hard for me to take it on.;-)
You, and many other people, are muddying the waters by confusing Xfree86, a specific implementation of an X server, with the underlying concept of an X server in general. It is impossible for X to be a "big dumb slow ram hog" because it is really a description of a protocol for a display server.
It's a bit like saying that ftp is a big slow ram hog.
Furthermore when you say that X has no consistent look and feel, you reveal your complete lack of understanding concerning X. As I said, X is a display server. It can't really detract from a consistent look and feel.
What you might mean is that you wish the linux community could standardize on a widget set to make apps have a more homogenous appearance, or something like that. This is a totally reasonable goal, and I'm not arguing against it. I'm just pointing out that it has nothing to do with X in general.
Configuration is also an Xfree86 specific complaint. I used to use an Xserver on windows that was quite easy to configure. In fact, I think that all I did was install it and it worked. Later I used another, much fancier one, and found it even harder to configure than Xfree86.
Anyway, PicoGUI is about as close to displacing Xwindows as Jolt cola is to displacing Coke as the pre-eminent Cola drink.
Well, I don't want to join the legion of lame, rabid, my-linux-right-or-wrong, flamers, but, well, your comment shows your ignorance about X, and I can't let it pass.
X is, conceptually, little more than a video driver that can work over the network. The fact that you mention X in the same breath (if you will) as gnome and KDE shows me that you don't really get what X is. Hopefully you do now.
As for the rest, I will take your word for it. I have no experience to the contrary.
Personally, I don't ask much of a window manager, and I don't have a desktop, so I am quite happy running gnome (using the enlightenment rip-off theme) and no nautilus.
I used to use enlightenment plus the graphical midnight commander, and that was almost perfect for me. One day I decided to try gnome, and now I'm too lazy to switch back. I did prefer enlightenment, though.
I would say, however, that if you don't like linux, you should continue to complain about the bits that give you trouble and ignore all the flamers. Some companies pay lots of money to find out what consumers think of their products. You are providing honest feedback for free.
Basically, everything depends on X, so you can't really replace X and maintain backwards compatibility. In order to have backwards compatibility, you would need to provide all the services provided by X, so you would, in effect, just be writing a new X server.
If you really want to replace X with some other system, then you could probably get pretty far by just porting gtk and motif over to the new system. This should pick up quite a few apps. I have no idea how hard this would be.
But, by and large, it's silly to constantly rant and rave about X. It's just an abstraction for a video driver that allows you to effortlessly traverse networks. It is so low level, that it almost doesn't make sense to criticize it. And I think many of the critics don't really understand fully what X is.
For example, if you don't like the performance, then that is a complaint against the specific Xserver you are running, not against X itself.
If you don't like the widgets you are using, then that is a complaint against the widget set you are using (motif, gtk, qt, etc.). This has nothing to do with X.
As far as features go, if you really want a feature and X does not provide it, then you have a legitimate complaint. But really, what more do you want from a video (and mouse and keyboard) driver than the ability to get information about GUI events and to paint the screen in any fashion you desire?
To sum up, I don't see that X is inherently problematic. I think that most complaints about it are misplaced, and should be directed elsewhere.
Furthermore, when people talk about replacing X, they seldom seem to appreciate the benefits of allowing the application to connect to the server over the network. This is one of X's strongest points, yet most people seem to want to replace it with what ammounts to a widget set rolled up with a local machine only video driver.
If you provide the X-windows service, then you are an X-server, whether you call yourself one or not. So I'm not sure what it would mean to emulate X. If you somehow support X plus some other features, then that would be more like extending X than emulating it.
Personally I don't have any problem with X. I like it. Most of the sensible complaints I hear about it seem to be coming from people who want features that aren't there yet, or who feel the performance isn't up to snuff. These are almost drowned out by people who don't really seem to understand what X does.
I mean, X is a fairly generic display system, as witnessed by the fact that blackbox, matchbox, twm, fvwm, enlightenment, etc, which all look very different, are all just X clients.
Anyway, it might be possible to address the features issue and still have emulation, but I don't think that performance issues will be solved by emulation. And, when you look at all the graphical programs that use X, it seems kind of hopeless to expect that X will go away and be replaced by something else.
Although, if you could port, say, motif and gtk to some new, non-X system, then you could probably leverage a lot of other stuff over to that system relatively quickly.
First of all, if you have a setup that works, then I would say that's great and stick with it. Don't change something that works on account of my comment.
But to answer your question, the USB power is not a current source. It is a voltage source. It is designed to stay at 5 volts and supply more or less current (up to some limit) if necessary to maintain that voltage.
A resistor in series with a voltage source is a sort of crude current source, but it is highly dependent on the load. That's why it might not work if you simply switch LED's. Ideally you should at least re-calculate the resistor value if you change from a red/yellow/orange/green LED to a blue one. The resistor value will be smaller for a blue LED.
A "real" current source would be designed to maintain some current, and raise or lower the voltage as necessary (within some limit) to maintain that current.
The simplest transistor current source is a matched pair of transistors in a configuration called a current mirror. You would have the matched pair, one resistor to set the current, and the LED as a load.
It is a bit tricky to describe without a diagram, but here is a url: http://www.ee.umd.edu/~bassel/man/lab6edit/n ode3.h tml
In the picture, the 10k resistor is setting the current to 1mA ((10.7V - 0.7 V)/10k=1mA) and R2 is acting as a load. No matter what the value of R2, the current through it will be 1mA. Naturally this is only true over some range. When R2 is greater than 10k, for example, it no longer works.
If you were to use this for a blue LED driver, you would put the LED where R2 is, and use 5 volts instead of 10.7, and calculate a new value instead of 10k. If you wanted 20 mA, for example, you would use (5V-0.7V)/20mA = 215 Ohms. So you could use 220 or 240 instead of 10k.
The 0.7 V is subtracted to account for the voltage drop from base to emitter in the transistors. This is an estimate, but it is close enough for what we are doing.
Obviously this replacement worked for the story's author, but there is a technical point I haven't seen raised yet: Blue LED's have a much higher forward voltage drop than red LED's, and will often not turn on all the way in a circuit designed for red LED's.
The typical red LED circuit is a resistor connected to 5 volts (sometimes 3.3) in series with the LED. The resistor limits the current that can pass through the LED. The value of the resistor is based on some typical forward voltage across the LED. That is, the 5 volts will end up being partially across the resistor, and partially across the LED. The resistor is calculated so that the typical voltage drop will yield the desired current.
The voltage drop on a red LED is about 1 or 1.5 volts or something (I don't remember exactly) but blue LED's ca drop around 3 or 4 volts (IIRC). This throws off the calculations used in selecting a current-limiting resistor for the typical (red) LED circuit. A 3.3 volt circuit might not even turn a blue LED on at all.
The best way to turn on a blue LED is to put it in series with a simple current source (this can just be one matched pair of transistors with a current setting resistor on one of them) or, when possible, to use 12 volts with a current-limiting resistor in series.
Green and yellow are close enough to red that they don't pose a problem.
Wired magazine wrote an article about a company (which was mostly just a front for one man) that fits your description.
It was pretty clear from the article that the guy was a crook and that there was nothing to his claims. But he got a lot of money from a lot of supposedly smart people.
By the way, what does the claim that "latency everywhere would be under 10ms" mean?
I think that they must just do a randomness test on it. I believe that a message decrypted with the wrong key would still be highly random, whereas a message of interest would contain a great deal of highly evident non-randomness.
One way to look at it is this: if you attempt to decrypt a message with the wrong key, you have, in fact, encrypted it a second time. You wouldn't expect the doubly encrypted message to make any sense or be obviously non-random.
Another way to look at it is this: the key space is MUCH smaller than the space of all messages of the correct length, so chances are slim that the wrong key would give a message which looked anyting but random.
I have never done this, but maybe I will now: I'll try to brute force decrypt a file of my own. I'll encode it and then actually try decoding it with a series of keys, and do some simple statistical tests on the output. For example, I can test the hypothesis that all bytes in the file appear with equal frequency, and if I can reject that hypothesis at some confidence level, then I'll know I've found the key. I'll have to brush up on my statistics first, I guess.
If the water started getting high and you started to fear for you life, kick off the weights, duck out of the bell, and swim to the surface. Not hard. Not risky. Hell I've been a lot further down than 20 feet with no air line or tanks...
You forgot the most important part: exhale all the way to the surface, otherwise you might very well die.
What happens is this: the air in your lungs, which is at ambient pressure, will try to expand on the way up. When your lungs reach full capacity, the air can expand only by rupturing alveoli in your lungs and forcing air bubbles into your circulatory system. Bubbles can impede the flow of blood to the point that you suffer stroke-like symptoms, including, possibly, death. This is called an air embolism.
The reason this doesn't happen when free diving (as when you descended to 20+ feet without any fancy aparatus) is that your lungs started out full at the surface, so they only expand back to the same fullness, at most. But any time you breathe air under water, you have to remember to let the air come out of your lungs during ascent, either by breathing in and out normally (when possible), or by exhaling continuously. If you practice a bit, you can actually learn to relax your breathing muscles so that air streams out naturally as you ascend.
The guys who were breathing underwater on the show were professionals as I recall, so they could be expected to know all this.
imagine if the Slapper worm was written so that it carried with it a public key, and used that key to verify any command sent to it. the worm could be designed to not even reply to UDP requests whose signature fail, making remote detection completely impossible
Encryption alone will not do this.
I agree that decrypting the udp packet would be computationally infeasible, assuming strong encryption. Likewise, forging arbitrary packets would be impossible for the same reason.
But you could still use a type of replay attack to flush out infected hosts. Once you capture a command packet (with a sniffer) and the characteristic response on an infected system, you can just resend that packet to another system and then if you see the characteristic response, you know the system is infected. This might not qualify as remote, since you would have to be in a position to observe the "expected response," which realistically means, you have to be on the same subnet.
I don't know. You are definitely on to something. There is probably a simple workaround for the replay attack I outlined. But I don't want to give anyone ideas. I don't want to give a design seminar for hard to detect worms.;-)
Labview used to (still does?) have an error dialog pop up that said "Error: insane object." In fairness to labview (an excellent piece of software IMHO) the error didn't come up often.
They also reportedly had an "Error: no error" message, although I never saw it.
Slashdot Mirror
Basically, you can't. If you don't have a recovery jumper, then flashing with a linux BIOS that doesn't work on your system is a one-way ticket.
In fact, even with the jumper you will most likely be hosed. In the two or three designs that I know about, all the jumper does is cause the OEM BIOS to restore the default settings. It doesn't change the actual BIOS code. So, if you replace the original BIOS with something totally different, I wouldn't expect the jumper to do anything at all.
The bottom line is, don't reflash unless you have a reason and have confidence that the new BIOS will at least boot DOS or some operating system that will let you flash back to the last known good version.
MM
--
The biggest power hog on an intel board is the CPU, followed by the northbridge (memory and pci part of the chipset).
Built-in accessories such as fibre-channel and/or gigabit ethernet currently also consume significant power.
Sometimes the power supply circuitry gets a bit hot as well, but only when it has to deliver ridiculous ammounts of current to a power-hog chip.
For example, current pentium mobile chip power supplies are supposed to be designed for upwards of 20 amps. This is at the core voltage, which varies depending on the speed-step state. IIRC the low setting is 1.15 V, and the higher setting is around 1.5 V or so. The maximum current case occurs at the higher voltage.
It's hard to pass 20 amps through a transistor or current sensing resistor or inductor without a little heat getting generated. You end up using 5 or 6 big transistors for the swithcing, and one or two big inductors, and very low resistance current sensing resistors. And you have to make the copper traces really wide, and use extra vias. To tell the truth, it's kind of a PITA. And if you, the engineer, screw up, the whole thing could catch on fire or fail in some other spectacular way.
MM
--
I'm not 100% sure that's true. Rockets are only aerodynamically stable, if at all, above some certain speed. It sounds as though this one may never have reached that speed, and much of the electronics seems to have failed very early on.
The guy, whatever his name is, seems to specifically allude to the rocket being stable because he says that in the event of an IMU failure, the main engine can continue to fire provided that the rocket is in the air and on an upward trajectory.
I wasn't able to watch the video, but I did read the post that reproduced the failure analysis.
MM
--
But, if someone says Xfree86 is too hard to configure, therefore we need to abandon Xwindows and completely change the fundamental way we do graphics on linux, then I would say, whoa, let's make sure we are making a good decision here!
Furthermore, a lot of people seem to think that window managers, desktop programs, and even widget sets are all somehow part of X. They say "X sucks" and then they rant and rave about stuff which is not directly related to the Xwindows system.
I have posted this basic idea too many times now under this article, so I don't want to go into it any more now. If you are really interested, check out my other posts.
MM
--
Interesting.
I don't know much about genetic algorithms and such, but I am aware of GAUL, a c-language based genetic algorithm library that is available on sourceforge.
Someday I'll have to look more deeply into these things, since the basic idea intrigues me.
MM
--
In that case, you should be trying to convince your favorite game developers to develop picoGUI (or whatever) versions of the game.
Also, I think that when you say "X" you are really talking about Xfree86, no?
Also, also, it sounds like there is no reason for you to use linux, so I'm not sure why you even care about this thread. Just stick to windows, if it makes you happy.
MM
--
what is ecj?
.java files that require a jvm. My idea is to fit java programs into the existing standard distribution mode of most open and free software where you do ./configure, make, make install.
./configure, make, and make install to install libswt, and then programs which use it can do the same. This allows a sun-free, and 100% free software solution to the java problem.
Is that just a typo for gcj?
The reason to use gcj and libswt is to have have binaries that are easy to execute, instead of
Personally I like java, but I don't like dealing with a jvm. And I think that from the perspective of a developer trying to gain acceptance for his or her free software project, the jvm burden is significant. On the other hand, if the distro comes with gcj, users can (eventually) just do
Perhaps it is a wrong-headed approach. It is certainly heresy from the perspective of the Sun orthodoxy. But getting away from non-free jvm's is a good thing, in my opinion.
MM
--
You have hit upon what sounds like a genuine criticism of X.
If the members of the vast horde of X critics were as knowledgeable on the topic of X as you appear to be, I would not defend X.
I just get tired of all the people saying "we need to get rid of Xwindows because XFree86 is too hard to configure" or "Xwindows is so slow, just look at how long it takes to change directories in Nautilus" or something like that.
I didn't realize that PicoGUI was intended to be network transparent. I did look at the page, but then I saw that they only had about 70 functions in their API, and weren't actually claiming to be a replacement for X in the first place. So I left.
MM
--
Check out this article or this project to see what I am talking about.
MM
--
I guess I basically agree.
Although, I just use linux because I like all the geeky stuff it can do and for philisophical reasons related to free software.
I don't mind not having a consistent look and feel across apps. I am not a linux evangelist, though. I don't try to convince people that they should switch, and I don't really care if people switch. I just want there to be enough people using it that it continues to be viable.
MM
--
Blame the clunkiness of the linux desktop on the linux desktop, not on X (in general) or Xfree86 in particular.
There are a lot of concepts associated with X on linux. X, in the form of Xfree86, is at the bottom. Then on top of that there is a widget toolkit (i.e., gtk+ or athena or motif).
Interacting with X is the window manager, which may use a widget toolkit, and which excercises control over placement, size and other characteristics of application windows. Each of these application windows gets to decide how the pixels it has control over should look, within the limitations of the display device. And, in many cases, these applications are built on top of a widget toolkit which may or may not be the same as the one used for the window manager. Then there is the "desktop" which is really just another application.
So, you see, "X" is probably not the cause of the clunkiness you perceive.
On the other hand, if Xfree86 is genuinely too slow, then you should build (or clamor for the building of) a faster x-server.
But don't throw out the whole concept of the x-server, for it gives us many benefits, perhaps most importantly, network transparency.
And, by the way, most people are not saying "Why change? X is ubiquitous!" They are either saying, "it will never happen: X is ubiquitous" or they are saying "Don't change it, because there isn't a superior alternative yet."
I, on the other hand, am saying "don't blame X for problems which lie elsewhere." And, perhaps, "don't put forth an opinion on X if you don't really know what it is."
Oh, and, "the PicoAPI has something like 70 functions in it. Let's not get carried away!"
MM
--
You may be right about the benefits of having a consistent look-and-feel.
;-)
But this has nothing to do with X. X is a low-level, display server technology. It has nothing to do with look-and-feel.
There is no reason related to X itself that we cannot have a consistent look and feel. All it would take is a concensus on the part of new developers. Also, if people are interested, they can always update some old classics (such as xv and gv) to use new widget sets. I have no idea how hard this would be, but I'm pretty sure it is too hard for me to take it on.
MM
--
You, and many other people, are muddying the waters by confusing Xfree86, a specific implementation of an X server, with the underlying concept of an X server in general. It is impossible for X to be a "big dumb slow ram hog" because it is really a description of a protocol for a display server.
It's a bit like saying that ftp is a big slow ram hog.
Furthermore when you say that X has no consistent look and feel, you reveal your complete lack of understanding concerning X. As I said, X is a display server. It can't really detract from a consistent look and feel.
What you might mean is that you wish the linux community could standardize on a widget set to make apps have a more homogenous appearance, or something like that. This is a totally reasonable goal, and I'm not arguing against it. I'm just pointing out that it has nothing to do with X in general.
Configuration is also an Xfree86 specific complaint. I used to use an Xserver on windows that was quite easy to configure. In fact, I think that all I did was install it and it worked. Later I used another, much fancier one, and found it even harder to configure than Xfree86.
Anyway, PicoGUI is about as close to displacing Xwindows as Jolt cola is to displacing Coke as the pre-eminent Cola drink.
MM
--
Well, I don't want to join the legion of lame, rabid, my-linux-right-or-wrong, flamers, but, well, your comment shows your ignorance about X, and I can't let it pass.
X is, conceptually, little more than a video driver that can work over the network. The fact that you mention X in the same breath (if you will) as gnome and KDE shows me that you don't really get what X is. Hopefully you do now.
As for the rest, I will take your word for it. I have no experience to the contrary.
Personally, I don't ask much of a window manager, and I don't have a desktop, so I am quite happy running gnome (using the enlightenment rip-off theme) and no nautilus.
I used to use enlightenment plus the graphical midnight commander, and that was almost perfect for me. One day I decided to try gnome, and now I'm too lazy to switch back. I did prefer enlightenment, though.
I would say, however, that if you don't like linux, you should continue to complain about the bits that give you trouble and ignore all the flamers. Some companies pay lots of money to find out what consumers think of their products. You are providing honest feedback for free.
MM
--
Wow, what a great idea! You should also design it so it can work over the network and then you would have, uh, well, you'd have X.
MM
--
Basically, everything depends on X, so you can't really replace X and maintain backwards compatibility. In order to have backwards compatibility, you would need to provide all the services provided by X, so you would, in effect, just be writing a new X server.
If you really want to replace X with some other system, then you could probably get pretty far by just porting gtk and motif over to the new system. This should pick up quite a few apps. I have no idea how hard this would be.
But, by and large, it's silly to constantly rant and rave about X. It's just an abstraction for a video driver that allows you to effortlessly traverse networks. It is so low level, that it almost doesn't make sense to criticize it. And I think many of the critics don't really understand fully what X is.
For example, if you don't like the performance, then that is a complaint against the specific Xserver you are running, not against X itself.
If you don't like the widgets you are using, then that is a complaint against the widget set you are using (motif, gtk, qt, etc.). This has nothing to do with X.
As far as features go, if you really want a feature and X does not provide it, then you have a legitimate complaint. But really, what more do you want from a video (and mouse and keyboard) driver than the ability to get information about GUI events and to paint the screen in any fashion you desire?
To sum up, I don't see that X is inherently problematic. I think that most complaints about it are misplaced, and should be directed elsewhere.
Furthermore, when people talk about replacing X, they seldom seem to appreciate the benefits of allowing the application to connect to the server over the network. This is one of X's strongest points, yet most people seem to want to replace it with what ammounts to a widget set rolled up with a local machine only video driver.
Well, that's my $0.02.
MM
--
If you provide the X-windows service, then you are an X-server, whether you call yourself one or not. So I'm not sure what it would mean to emulate X. If you somehow support X plus some other features, then that would be more like extending X than emulating it.
Personally I don't have any problem with X. I like it. Most of the sensible complaints I hear about it seem to be coming from people who want features that aren't there yet, or who feel the performance isn't up to snuff. These are almost drowned out by people who don't really seem to understand what X does.
I mean, X is a fairly generic display system, as witnessed by the fact that blackbox, matchbox, twm, fvwm, enlightenment, etc, which all look very different, are all just X clients.
Anyway, it might be possible to address the features issue and still have emulation, but I don't think that performance issues will be solved by emulation. And, when you look at all the graphical programs that use X, it seems kind of hopeless to expect that X will go away and be replaced by something else.
Although, if you could port, say, motif and gtk to some new, non-X system, then you could probably leverage a lot of other stuff over to that system relatively quickly.
MM
--
First of all, if you have a setup that works, then I would say that's great and stick with it. Don't change something that works on account of my comment.
n ode3.h tml
But to answer your question, the USB power is not a current source. It is a voltage source. It is designed to stay at 5 volts and supply more or less current (up to some limit) if necessary to maintain that voltage.
A resistor in series with a voltage source is a sort of crude current source, but it is highly dependent on the load. That's why it might not work if you simply switch LED's. Ideally you should at least re-calculate the resistor value if you change from a red/yellow/orange/green LED to a blue one. The resistor value will be smaller for a blue LED.
A "real" current source would be designed to maintain some current, and raise or lower the voltage as necessary (within some limit) to maintain that current.
The simplest transistor current source is a matched pair of transistors in a configuration called a current mirror. You would have the matched pair, one resistor to set the current, and the LED as a load.
It is a bit tricky to describe without a diagram, but here is a url:
http://www.ee.umd.edu/~bassel/man/lab6edit/
In the picture, the 10k resistor is setting the current to 1mA ((10.7V - 0.7 V)/10k=1mA) and R2 is acting as a load. No matter what the value of R2, the current through it will be 1mA. Naturally this is only true over some range. When R2 is greater than 10k, for example, it no longer works.
If you were to use this for a blue LED driver, you would put the LED where R2 is, and use 5 volts instead of 10.7, and calculate a new value instead of 10k. If you wanted 20 mA, for example, you would use (5V-0.7V)/20mA = 215 Ohms. So you could use 220 or 240 instead of 10k.
The 0.7 V is subtracted to account for the voltage drop from base to emitter in the transistors. This is an estimate, but it is close enough for what we are doing.
MM
--
Obviously this replacement worked for the story's author, but there is a technical point I haven't seen raised yet: Blue LED's have a much higher forward voltage drop than red LED's, and will often not turn on all the way in a circuit designed for red LED's.
The typical red LED circuit is a resistor connected to 5 volts (sometimes 3.3) in series with the LED. The resistor limits the current that can pass through the LED. The value of the resistor is based on some typical forward voltage across the LED. That is, the 5 volts will end up being partially across the resistor, and partially across the LED. The resistor is calculated so that the typical voltage drop will yield the desired current.
The voltage drop on a red LED is about 1 or 1.5 volts or something (I don't remember exactly) but blue LED's ca drop around 3 or 4 volts (IIRC). This throws off the calculations used in selecting a current-limiting resistor for the typical (red) LED circuit. A 3.3 volt circuit might not even turn a blue LED on at all.
The best way to turn on a blue LED is to put it in series with a simple current source (this can just be one matched pair of transistors with a current setting resistor on one of them) or, when possible, to use 12 volts with a current-limiting resistor in series.
Green and yellow are close enough to red that they don't pose a problem.
MM
--
Wired magazine wrote an article about a company (which was mostly just a front for one man) that fits your description.
It was pretty clear from the article that the guy was a crook and that there was nothing to his claims. But he got a lot of money from a lot of supposedly smart people.
By the way, what does the claim that "latency everywhere would be under 10ms" mean?
MM
--
I've always wondered about this, too.
I think that they must just do a randomness test on it. I believe that a message decrypted with the wrong key would still be highly random, whereas a message of interest would contain a great deal of highly evident non-randomness.
One way to look at it is this: if you attempt to decrypt a message with the wrong key, you have, in fact, encrypted it a second time. You wouldn't expect the doubly encrypted message to make any sense or be obviously non-random.
Another way to look at it is this: the key space is MUCH smaller than the space of all messages of the correct length, so chances are slim that the wrong key would give a message which looked anyting but random.
I have never done this, but maybe I will now: I'll try to brute force decrypt a file of my own. I'll encode it and then actually try decoding it with a series of keys, and do some simple statistical tests on the output. For example, I can test the hypothesis that all bytes in the file appear with equal frequency, and if I can reject that hypothesis at some confidence level, then I'll know I've found the key. I'll have to brush up on my statistics first, I guess.
--
MM
You forgot the most important part: exhale all the way to the surface, otherwise you might very well die.
What happens is this: the air in your lungs, which is at ambient pressure, will try to expand on the way up. When your lungs reach full capacity, the air can expand only by rupturing alveoli in your lungs and forcing air bubbles into your circulatory system. Bubbles can impede the flow of blood to the point that you suffer stroke-like symptoms, including, possibly, death. This is called an air embolism.
The reason this doesn't happen when free diving (as when you descended to 20+ feet without any fancy aparatus) is that your lungs started out full at the surface, so they only expand back to the same fullness, at most. But any time you breathe air under water, you have to remember to let the air come out of your lungs during ascent, either by breathing in and out normally (when possible), or by exhaling continuously. If you practice a bit, you can actually learn to relax your breathing muscles so that air streams out naturally as you ascend.
The guys who were breathing underwater on the show were professionals as I recall, so they could be expected to know all this.
MM
--
Encryption alone will not do this.
I agree that decrypting the udp packet would be computationally infeasible, assuming strong encryption. Likewise, forging arbitrary packets would be impossible for the same reason.
But you could still use a type of replay attack to flush out infected hosts. Once you capture a command packet (with a sniffer) and the characteristic response on an infected system, you can just resend that packet to another system and then if you see the characteristic response, you know the system is infected. This might not qualify as remote, since you would have to be in a position to observe the "expected response," which realistically means, you have to be on the same subnet.
I don't know. You are definitely on to something. There is probably a simple workaround for the replay attack I outlined. But I don't want to give anyone ideas. I don't want to give a design seminar for hard to detect worms. ;-)
MM
--
Nobody knows for sure where Columbus landed.
But one thing is almost for sure: it wasn't the mainland of what we now call the US.
You can check it out here.
MM
--
Labview used to (still does?) have an error dialog pop up that said "Error: insane object." In fairness to labview (an excellent piece of software IMHO) the error didn't come up often.
They also reportedly had an "Error: no error" message, although I never saw it.
--
MM