Disabling TTY switching is a pretty simple change, though, and won't affect the general use of the system.
In fact, you might as well use this to your advantage: start up a new X server instance, but don't start up the window manager. Run your java app in this server.
Now all a student can do is take the test -- there's no way to do anything besides take the test unless they can switch using ctrl-alt-F*, which has been disabled.
1) Making elements that large is really, really hard 2) Even if there exists an element with a half-life of, say, a few million years, it's been so long since the last supernova that finding one of them in nature would be impossible. 3) We're just now producing elements in the range where we might find more stable elements (according to current theory). These are exciting times, as we explore the boundaries of what we believe to be the island of stability.
When compared to the cost of a light bulb, a couple of bucks is still a lot. An incandescent costs less than a buck, a fluorescent (the real competitor that LED has to beat) about $3 or less. LED bulbs are still very expensive, and price varies a lot. Let's say $10 for the cheapest. I'm sure the price will come down even more.
In the end, though, you're right. It's easy to forget just how cheap electronics can be. And it really only has to supply 10A or less.
Linear regulators (like the 7805) are stupidly inefficient. Not too bad if you're regulating down only a bit, which is why they're used to supply the variety of voltages on a single motherboard. The problem is that an LDO supplying 1A at 5V will draw >1A at 12V. About 40% efficient (5/12).
Better are DC/DC buck converters. These cost less than a buck in bulk and are about 85% efficient or better (I've heard 95%). I'm not sure what the efficiency would be for high-current applications.
The biggest disadvantage with buck converters, in my opinion, is the extra design effort that goes into using one. A 7805 just needs a few capacitors (and even those aren't really a big deal for many applications). Buck converters need a Schottky diode, an inductor, and a couple capacitors, and sometimes more. Kinda keeps them outside the realm of hobbyists.
Well, it's not exactly a transformer, but you're essentially correct -- a high-power LED bulb needs to be supplied its forward voltage at a constant current, which means rectifying and bucking the voltage down. There's lots of schemes to do this, some more efficient than others. The current limiting resistor scheme most of us are familiar with is about the most inefficient way, but it's also very inexpensive. LDOs and linear regulators are still very inefficient. Buck converters are better, but very expensive.
In the end, that conversion has to happen no matter what, whether at the bulb or at a central box somewhere else, so there's always going to be some wasted energy. Hopefully you'll get improved efficiency by centralizing everything.
But, even if the overall efficiency is the same, there's still the benefit of moving the heat to a different location. One major problem with LED bulbs is that they dim and can handle less current as they heat up. Notice the heat sinks they're putting on the really high power LEDs these days. Performing the voltage conversion elsewhere means that this heat is moved elsewhere.
And if you're smart about where "elsewhere" is located, you're also reducing the strain on the air conditioners! Put the conversion in a basement or outside the building, for example.
I wonder how much of the heat produced in a data center is actually produced by the power supplies for each server. 10% to 20% feels about right. Ignoring any other benefits of moving to DC, I would think that the 20% reduction on the air conditioning bill would be justification enough.
Good news! If I'm reading Groklaw correctly, Google's starting to get involved.
I think the reason Google hasn't really been involved before is because Microsoft hasn't been attacking them directly. And because companies have just been rolling over, Google hasn't had a chance to back anybody up.
Google will become involved now that someone is planting their feet, hopefully.
I think a key point here is that we don't yet know what is happening, only that we got some unexpected result, and we can't yet explain it.
The most science-shattering explanation is that the neutrinos exceeded the speed of light, so naturally that's what everybody wants to believe. Unfortunately, these sorts of things tend to have more mundane explanations, ranging from the lame ("whoops, measurement error") to the still-pretty-cool (a new effect of relativity).
On the other hand, it's also possible that this new finding really is that fundamentally important. Could it even explain dark matter or dark energy? Might it lead to FTL transportation, or at least FTL communication? After all, we're dealing with neutrinos, which are quite a bit mysterious already.
Everyone, myself included, really wants all this cools stuff to be true. But, pardon me if I take all this with a grain of salt for now.
I can't decide if you should be modded informative or troll for revealing how the trick works. If I had mod points, I think I'd go for insightful, for pointing out how this whole thing applies to the study in question.
The fallacy is that any metric (lines of code, number bugs reports closed, mean time to complete fixes, etc.) or a combination thereof can differentiate between the programmers that should be promoted and those that should be fired. The assumption is that "good programmers" write more lines of code, fix more bugs, make the code run faster, or even write code that optimizes some arbitrary complexity metric. In fact, a "good programmer" does none of these things.
A "good programmer" doesn't necessarily create or changes lots of code. This is especially true of older code. Some of the most intricate fixes I've ever had to make only involved a couple of characters on a single line.
A "good programmer" puts in useful comments, which line of code counters usually exclude.
A "good programmer" will fix a bug the right way the first time, and doesn't race to close bugs. However, a "good programmer" will close as many bugs as possible, as the thought of an unfixed software bug produces the same emotions as knowing real live bugs live in your computer.
Well, so much for the objective measures. How about some subjective ones?
A "good programmer" will write code that others will find a pleasure to work with later. Not necessarily bug-free, but fixing those bugs are simple. Extending functionality doesn't break everything all over again. Reusing functions is a breeze. Everything's well-documented.
A "good programmer" gets the job done. Easy tasks will be completed quickly, difficult tasks will be completed after some time, but both will be "well done."
A "good programmer" will test all code as thoroughly as necessary. This means that odd corner cases are considered and accounted for, that error conditions are handled gracefully.
A "good programmer" will find and fix bugs, refactoring and cleaning up code with each change. Code runs and even looks better after a "good programmer" works with it, even in passing.
Metrics say absolutely nothing about a programmer. And yet, I can tell you exactly which programmers I work with actually know what they're doing and produce good results. I know which ones will help the company make money. I know which ones will meet deadlines. And I also know which ones I'll be cleaning up after later on. I know of no metric that can tell me this, so yes, it's purely subjective.
This is generally a good policy; on the other hand, as soon as a case for reuse is made (such as when new features are added), the shared code should be refactored out. In my experience, the first time I duplicate functionality is never the last time. And don't wait for the thirteenth reuse, either, as refactoring each into a common subset can be just about impossible.
All EEs who aren't old enough to have been retired long ago have taken courses on logic design. Things like state machines or indirect addressing come naturally to them. Software is a natural evolution from circuit design.
That used to be the case. But software has evolved a couple times since then, and we've gone further and further away from software that just acts like a state machine. Lots of programmers don't understand indirect addressing anymore.
Phew! I thought I was the only person who noticed this.
My undergrad degree is EE, but I'd already been writing code well before. Seeing some of my classmates code was very, very painful. And it's not just a matter of experience, more like a mindset.
I think the main problem is that EE's live in a world of very strict boundaries. Voltages that are guaranteed to be in a certain range. Logic that must fit within a specific clock cycle. As long as they stay within the specified boundaries in the datasheet, they're all set. And once you get something to work within those parameters, that's that. I exaggerate somewhat, of course.
Software is different. Here, you interface with users. All communication is asynchronous -- no strict clock cycles. The software equivalent of a datasheet is the API documentation, and I would kill for it to be as clear and precise as what I see for electronics.
Reading back over that, it makes it seem like software is more difficult than hardware -- that was not my intention. (Actually, I think the reverse is true.) But, I think it shows why EE's generally write poor code -- they have a hard time imagining a world that doesn't work with the same precision they're used to.
The reverse happens when software people try to make hardware, especially now that software has become so abstracted from the hardware it runs on. Programmers have a hard time fitting within these same tight constraints that hardware requires.
Corrrect. It's probably better to describe the 4004 as BCD (Binary Coded Decimal) rather than as "four bit." Storing a number larger than 9 requires eight bits, the first four store the first digit, and the second four store the second digit. The bit patterns 0xA through 0xF were actually special patterns used for various things (like marking negative numbers).
Since the original purpose of the 4004 was a calculator, this system makes a lot of sense. It might not be the most efficient use of bits (an eight-digit decimal number uses 32 bits in BCD, but requires only 27 bits when in binary), but it makes the translation to and from human-readable formats very easy.
This is exactly how most circuits using discrete logic operated, and for the exact same reason. In fact, I'm working on a project right now that uses only discrete logic -- encoding in BCD makes the whole thing possible. Using BCD on the first microprocessor makes lots of sense as an incremental improvement on what people already did.
You're right -- it's not really 16 cores. But nor is it just 8 cores with HyperThreading. Bulldozer is an interesting compromise that gives every concurrent thread of execution its own set of computation resources. This should result in faster execution than an 8-core machine, with or without hyperthreading, but probably isn't quite as faster as a true 16-core machine.
Also, (and I might be very wrong here), I thought there were 16 floating point units, too.
I'm really getting tired of all the whining about fragmentation. You're absolutely right -- on the desktop market, fragmentation has actually been a good thing. But on desktop computers we call it "competition" and "diversity" and "choice."
From a consumer's point of view, there's absolutely nothing to lose from this fragmentation. Look at the alternative: completely different, incompatible operating systems from each manufacturer. The differences in android version and hardware capabilities are nothing in comparison.
But, I don't really see consumers complaining. It's the app developers who are whining.
[sarcasm]Yeah, it's just so hard to write code that works on more than one device. It's not like we haven't been doing that for, oh, about the whole history of computing or anything.[/sarcasm]
I'll admit, it's one more thing to think about while programming, and one more thing to get wrong, but I've learned that more often than not "Fragmentation" is just another word for "FUD."
I once helped a friend with his computer. He had recently built a computer and was trying to overclock it, but the thing was severely overheating constantly, even when not overclocked. He asked me to look at his setup. I expected to see an unplugged fan, or maybe missing thermal paste or something.
Well, it turned out that he decided to get the most massive heatsink/fan combo he could for his Core i7 (they had just come out, I think)... and it was just a hair too big for his case.
He cut off the ends of the heat pipes to get it to fit.
He said he was surprised the pipe wasn't solid. I'm not sure what he thought about the fluid inside.
Slashdot Mirror
Disabling TTY switching is a pretty simple change, though, and won't affect the general use of the system.
In fact, you might as well use this to your advantage: start up a new X server instance, but don't start up the window manager. Run your java app in this server.
Now all a student can do is take the test -- there's no way to do anything besides take the test unless they can switch using ctrl-alt-F*, which has been disabled.
That's as near to a "kiosk mode" as I can figure.
We haven't found them yet because:
1) Making elements that large is really, really hard
2) Even if there exists an element with a half-life of, say, a few million years, it's been so long since the last supernova that finding one of them in nature would be impossible.
3) We're just now producing elements in the range where we might find more stable elements (according to current theory). These are exciting times, as we explore the boundaries of what we believe to be the island of stability.
When compared to the cost of a light bulb, a couple of bucks is still a lot. An incandescent costs less than a buck, a fluorescent (the real competitor that LED has to beat) about $3 or less. LED bulbs are still very expensive, and price varies a lot. Let's say $10 for the cheapest. I'm sure the price will come down even more.
In the end, though, you're right. It's easy to forget just how cheap electronics can be. And it really only has to supply 10A or less.
Linear regulators (like the 7805) are stupidly inefficient. Not too bad if you're regulating down only a bit, which is why they're used to supply the variety of voltages on a single motherboard. The problem is that an LDO supplying 1A at 5V will draw >1A at 12V. About 40% efficient (5/12).
Better are DC/DC buck converters. These cost less than a buck in bulk and are about 85% efficient or better (I've heard 95%). I'm not sure what the efficiency would be for high-current applications.
The biggest disadvantage with buck converters, in my opinion, is the extra design effort that goes into using one. A 7805 just needs a few capacitors (and even those aren't really a big deal for many applications). Buck converters need a Schottky diode, an inductor, and a couple capacitors, and sometimes more. Kinda keeps them outside the realm of hobbyists.
Well, it's not exactly a transformer, but you're essentially correct -- a high-power LED bulb needs to be supplied its forward voltage at a constant current, which means rectifying and bucking the voltage down. There's lots of schemes to do this, some more efficient than others. The current limiting resistor scheme most of us are familiar with is about the most inefficient way, but it's also very inexpensive. LDOs and linear regulators are still very inefficient. Buck converters are better, but very expensive.
In the end, that conversion has to happen no matter what, whether at the bulb or at a central box somewhere else, so there's always going to be some wasted energy. Hopefully you'll get improved efficiency by centralizing everything.
But, even if the overall efficiency is the same, there's still the benefit of moving the heat to a different location. One major problem with LED bulbs is that they dim and can handle less current as they heat up. Notice the heat sinks they're putting on the really high power LEDs these days. Performing the voltage conversion elsewhere means that this heat is moved elsewhere.
And if you're smart about where "elsewhere" is located, you're also reducing the strain on the air conditioners! Put the conversion in a basement or outside the building, for example.
I wonder how much of the heat produced in a data center is actually produced by the power supplies for each server. 10% to 20% feels about right. Ignoring any other benefits of moving to DC, I would think that the 20% reduction on the air conditioning bill would be justification enough.
"No, you just make the dress look small."
Maybe they can point MRO at it instead. It's not as if it hasn't been done before.
And in the meantime, the patents they bring out will probably be invalidated.
Well, that certainly explains why the patents they're using in this suit are so laughable. Disposable ammunition.
Maybe a partnership between B&N and Google Books?
Good news! If I'm reading Groklaw correctly, Google's starting to get involved.
I think the reason Google hasn't really been involved before is because Microsoft hasn't been attacking them directly. And because companies have just been rolling over, Google hasn't had a chance to back anybody up.
Google will become involved now that someone is planting their feet, hopefully.
I think a key point here is that we don't yet know what is happening, only that we got some unexpected result, and we can't yet explain it.
The most science-shattering explanation is that the neutrinos exceeded the speed of light, so naturally that's what everybody wants to believe. Unfortunately, these sorts of things tend to have more mundane explanations, ranging from the lame ("whoops, measurement error") to the still-pretty-cool (a new effect of relativity).
On the other hand, it's also possible that this new finding really is that fundamentally important. Could it even explain dark matter or dark energy? Might it lead to FTL transportation, or at least FTL communication? After all, we're dealing with neutrinos, which are quite a bit mysterious already.
Everyone, myself included, really wants all this cools stuff to be true. But, pardon me if I take all this with a grain of salt for now.
I can't decide if you should be modded informative or troll for revealing how the trick works. If I had mod points, I think I'd go for insightful, for pointing out how this whole thing applies to the study in question.
You deserve to be modded up, you do.
The fallacy is that any metric (lines of code, number bugs reports closed, mean time to complete fixes, etc.) or a combination thereof can differentiate between the programmers that should be promoted and those that should be fired. The assumption is that "good programmers" write more lines of code, fix more bugs, make the code run faster, or even write code that optimizes some arbitrary complexity metric. In fact, a "good programmer" does none of these things.
A "good programmer" doesn't necessarily create or changes lots of code. This is especially true of older code. Some of the most intricate fixes I've ever had to make only involved a couple of characters on a single line.
A "good programmer" puts in useful comments, which line of code counters usually exclude.
A "good programmer" will fix a bug the right way the first time, and doesn't race to close bugs. However, a "good programmer" will close as many bugs as possible, as the thought of an unfixed software bug produces the same emotions as knowing real live bugs live in your computer.
Well, so much for the objective measures. How about some subjective ones?
A "good programmer" will write code that others will find a pleasure to work with later. Not necessarily bug-free, but fixing those bugs are simple. Extending functionality doesn't break everything all over again. Reusing functions is a breeze. Everything's well-documented.
A "good programmer" gets the job done. Easy tasks will be completed quickly, difficult tasks will be completed after some time, but both will be "well done."
A "good programmer" will test all code as thoroughly as necessary. This means that odd corner cases are considered and accounted for, that error conditions are handled gracefully.
A "good programmer" will find and fix bugs, refactoring and cleaning up code with each change. Code runs and even looks better after a "good programmer" works with it, even in passing.
Metrics say absolutely nothing about a programmer. And yet, I can tell you exactly which programmers I work with actually know what they're doing and produce good results. I know which ones will help the company make money. I know which ones will meet deadlines. And I also know which ones I'll be cleaning up after later on. I know of no metric that can tell me this, so yes, it's purely subjective.
And the "reusable" version very often isn't reusable at all, since the original coder didn't properly envision what other use cases would look like.
This is generally a good policy; on the other hand, as soon as a case for reuse is made (such as when new features are added), the shared code should be refactored out. In my experience, the first time I duplicate functionality is never the last time. And don't wait for the thirteenth reuse, either, as refactoring each into a common subset can be just about impossible.
I'm watching you.
Whoops, I didn't realize anybody was watching.
(/me puts down his balls)
Actually, it refers to a teddy bear. Kinda cute, with unfortunate implications to the American ear.
All EEs who aren't old enough to have been retired long ago have taken courses on logic design. Things like state machines or indirect addressing come naturally to them. Software is a natural evolution from circuit design.
That used to be the case. But software has evolved a couple times since then, and we've gone further and further away from software that just acts like a state machine. Lots of programmers don't understand indirect addressing anymore.
Phew! I thought I was the only person who noticed this.
My undergrad degree is EE, but I'd already been writing code well before. Seeing some of my classmates code was very, very painful. And it's not just a matter of experience, more like a mindset.
I think the main problem is that EE's live in a world of very strict boundaries. Voltages that are guaranteed to be in a certain range. Logic that must fit within a specific clock cycle. As long as they stay within the specified boundaries in the datasheet, they're all set. And once you get something to work within those parameters, that's that. I exaggerate somewhat, of course.
Software is different. Here, you interface with users. All communication is asynchronous -- no strict clock cycles. The software equivalent of a datasheet is the API documentation, and I would kill for it to be as clear and precise as what I see for electronics.
Reading back over that, it makes it seem like software is more difficult than hardware -- that was not my intention. (Actually, I think the reverse is true.) But, I think it shows why EE's generally write poor code -- they have a hard time imagining a world that doesn't work with the same precision they're used to.
The reverse happens when software people try to make hardware, especially now that software has become so abstracted from the hardware it runs on. Programmers have a hard time fitting within these same tight constraints that hardware requires.
If all code were GPL, handset makers couldn't close off the phones. Then this problem would be easy to fix.
(Just to head off the GPL vs BSD vs whatever debates, I'm not trying to take sides here, just sharing a thought I had.)
Corrrect. It's probably better to describe the 4004 as BCD (Binary Coded Decimal) rather than as "four bit." Storing a number larger than 9 requires eight bits, the first four store the first digit, and the second four store the second digit. The bit patterns 0xA through 0xF were actually special patterns used for various things (like marking negative numbers).
Since the original purpose of the 4004 was a calculator, this system makes a lot of sense. It might not be the most efficient use of bits (an eight-digit decimal number uses 32 bits in BCD, but requires only 27 bits when in binary), but it makes the translation to and from human-readable formats very easy.
This is exactly how most circuits using discrete logic operated, and for the exact same reason. In fact, I'm working on a project right now that uses only discrete logic -- encoding in BCD makes the whole thing possible. Using BCD on the first microprocessor makes lots of sense as an incremental improvement on what people already did.
You're right -- it's not really 16 cores. But nor is it just 8 cores with HyperThreading. Bulldozer is an interesting compromise that gives every concurrent thread of execution its own set of computation resources. This should result in faster execution than an 8-core machine, with or without hyperthreading, but probably isn't quite as faster as a true 16-core machine.
Also, (and I might be very wrong here), I thought there were 16 floating point units, too.
There is no connection between taxes and spending that I can see.
Exactly. Lately, it seems like we'll just spend and spend regardless of tax policy.
I'm really getting tired of all the whining about fragmentation. You're absolutely right -- on the desktop market, fragmentation has actually been a good thing. But on desktop computers we call it "competition" and "diversity" and "choice."
From a consumer's point of view, there's absolutely nothing to lose from this fragmentation. Look at the alternative: completely different, incompatible operating systems from each manufacturer. The differences in android version and hardware capabilities are nothing in comparison.
But, I don't really see consumers complaining. It's the app developers who are whining.
[sarcasm]Yeah, it's just so hard to write code that works on more than one device. It's not like we haven't been doing that for, oh, about the whole history of computing or anything.[/sarcasm]
I'll admit, it's one more thing to think about while programming, and one more thing to get wrong, but I've learned that more often than not "Fragmentation" is just another word for "FUD."
True story:
I once helped a friend with his computer. He had recently built a computer and was trying to overclock it, but the thing was severely overheating constantly, even when not overclocked. He asked me to look at his setup. I expected to see an unplugged fan, or maybe missing thermal paste or something.
Well, it turned out that he decided to get the most massive heatsink/fan combo he could for his Core i7 (they had just come out, I think) ... and it was just a hair too big for his case.
He cut off the ends of the heat pipes to get it to fit.
He said he was surprised the pipe wasn't solid. I'm not sure what he thought about the fluid inside.