On the other hand, there'd be a hell of a tax break for someone shown as paying 23 quadrillion dollars to the Visa CEO's favourite charity. Lifetime immunity?
Just as importantly, if there's one obviously corrupt item in the database, couldn't any transaction record have been corrupted by the error? If Visa isn't willing to supply the code to a third-party for inspection, then clearly the entire bill for that month has to be voided.
(Given the economy these days, that could be just as much as any direct damages awarded.)
CoreBoot (formerly known as LinuxBIOS) will boot a full Linux kernel on a general-purpose machine in 3 seconds. Ok, it's two seconds longer, but it ain't bad.
This makes it great for wireless networks in which routes are highly variable or not otherwise knowable in advance. Routing protocols already exist for such indeterminate networks, but if the protocol you're transmitting has too short a timeout, it's useless. You'd lose far too many packets and never get any work done.
So, for such networks, you'd need DTN. DTN would also be useful when using Mobile IP, where the two networks you're crossing between have a gap between them, so there isn't 100% coverage. Then, your connection can survive the transition, even though you don't have actual connectivity for all of that time.
Given that DTN sits between two layers already in the kernel, it'd be stupid to have DTN in userspace. (Stupid and potentially dangerous, as you then have a userspace app injecting data into a fairly low level part of the kernel in a way that would have to bypass a lot of safeguards.)
As for stuff that's in the kernel that shouldn't be - want to give some examples? I can think of a few things that are probably not great, but I can't think of anything that absolutely shouldn't be there.
It sits between the Ethernet and TCP/UDP layers. Where the hell do you think it's going to sit? On top of the monitor? The only way you could add DTN except in the kernel is via netfilter (which would make this not only Linux-specific but also firewall technology specific, as netfilter is being replaced).
Adding DTN in userspace via netfilter would (a) add some very stupid and unnecessary context switches, and (b) totally subvert the purpose for which netfilter is designed, not for technical reasons but political ones.
But there's nowhere else you can put it, if you want to run DTN in userspace. Which means you either have a totally stupid, farcical solution OR a kernel implementation.
Until Linux and the *BSDs have DTN as standard, you're not likely to see anything serious using it. DTN could be seriously useful in a lot of circumstances, but look at the hassle getting multicasting or IPv6 - and these are protocols that have long been supported both in ISPs routers and the OS' in people's homes.
No, it doesn't break net neutrality in and of itself, any more than a traffic light or a roundabout breaks road neutrality. The idea of routing flows, rather than packets, permits more packets to get through for the same bandwidth.
So long as all flows are treated fairly, this will actually BOOST network neutrality as network companies will have less justification to throttle back protocols which take disproportionate bandwidth - as they will no longer do so. Users will also have less cause to complain, as the effective bandwidth will move closer to the theoretical bandwidth.
The only concern is if corporations and ISPs use this sort of router to discriminate against flows (ie: ensure unfair usage) rather than to improve the quality of the service (ie: ensure fair usage).
The belief by ISPs that you cannot have high throughput unless you block legitimate users is nothing more than FUD. It has no basis in reality. It is possible, by moving away from best-effort and towards fair-effort, to get higher throughput for everyone.
Congested networks can be modeled as turbulent flow in a river. Blocking streams is like damming up some of the tributary streams. It causes a lot of grief and isn't really that effective.
On the other hand, smoothing out the turbulence will improve the throughput without having to dam up anything. QoS services are intended as smoothing mechanisms, not dams. For the most part, at least.
Most "net neutrality" advocates would be advised to focus only on the efforts to build gigantic dams, rather than to be unkind or unfair on those merely smoothing the way, with no bias or discrimination intended.
Somewhere I've the circuit diagram for those in an old Wireless World. Popular in PoW camps as well as in the trenches in WW2, apparently, as they could be easily assembled, easily hidden and the parts could be smuggled in via Red Cross parcels.
If the light-sensitive components are not directional, you could have the clock emitter ABOVE the silicon on a completely independent layer. That wouldn't require them to perfect the transmission side, so could be done a lot quicker.
That's cool, but with modern chip designs using electron tunneling for some of the effects, it can't be used chip-wide. On the other hand, light can cross through light, so you would be able to avoid tediously long tracks currently required.
There may be some additional interest in the aerospace industry for this. Optical circuits on the chips aren't going to be so affected by radiation, and by having more real-estate available for redundant components and optimal placement, they can improve the resistance to radiation considerably.
Not sure how much heat this'll cut down on, as the transistors are the big heat-producers. On the other hand, better placement means more even heat production which means they should be able to push the designs a little bit further.
I'm not convinced these machines will, but the pain suffered when they are erased so publicly might result in greater investment in security.
On the other hand, users and corporations alike often rely on the "many targets, few victims" principle that says that it's only other people who are likely to be hurt.
Sad to say, short of Governments imposing minimum standards for IT security (just the same as they impose minimum standards for car safety in many countries), the best hope might actually be a major disaster, as ironic as that sounds. Sometimes, burned hands really do learn the best, as much as I hate that line of thinking.
It only requires one post to get karma, right? And once someone has posted and successfully acquired karma legitimately, there's nothing further to be done and all other posts are a waste.:)
Seriously, I agree with you. The AC who started this thread is an idiot.
Not that I recall. It used an ultra-cold medium, IIRC. I think this article may be discussing the same thing. However, there seems to be other ways to reduce the speed of light to manageable levels, which is interesting.
It was done back in the days of MUD 1 (Essex MUD). (Before anyone asks, yes, I did use the summon spell followed by the sleep spell, followed by the broadsword, quite a bit. Why do you ask?)
Lord Baden-Powell, founder of the boy scout movement, was a spy for the British Army. He encoded maps of enemy encampments as decorations on butterfly wings. Were those maps found 500 years from now with no context, they'd appear to be insects which are not known on Earth.
I'm not saying this is the case here, merely that we can't trust what we assume we know merely because the assumption looks like it might be right. If it didn't look right, it wouldn't be assumed. It doesn't make the assumption reliable.
Another example would be the Sumerian cuneiform for house. It's a tent peg. True, we know what tent pegs are, but the Sumerians had abandoned nomadic living 500-1000 years before they developed writing. If we went by what they knew, we'd never be able to reconcile what they drew with what was present.
The thing is, we know Linear A was indeed in Minoan Crete and we know a fair bit about Minoan Crete. Although we know a lot about 16th century Europe as a whole, it could be absolutely anywhere in Europe and the amount that is common across the whole of Europe back then was exceedingly small.
Slashdot Mirror
On the other hand, there'd be a hell of a tax break for someone shown as paying 23 quadrillion dollars to the Visa CEO's favourite charity. Lifetime immunity?
Just as importantly, if there's one obviously corrupt item in the database, couldn't any transaction record have been corrupted by the error? If Visa isn't willing to supply the code to a third-party for inspection, then clearly the entire bill for that month has to be voided.
(Given the economy these days, that could be just as much as any direct damages awarded.)
So what you're saying is that your message booted too quickly.
CoreBoot (formerly known as LinuxBIOS) will boot a full Linux kernel on a general-purpose machine in 3 seconds. Ok, it's two seconds longer, but it ain't bad.
This makes it great for wireless networks in which routes are highly variable or not otherwise knowable in advance. Routing protocols already exist for such indeterminate networks, but if the protocol you're transmitting has too short a timeout, it's useless. You'd lose far too many packets and never get any work done.
So, for such networks, you'd need DTN. DTN would also be useful when using Mobile IP, where the two networks you're crossing between have a gap between them, so there isn't 100% coverage. Then, your connection can survive the transition, even though you don't have actual connectivity for all of that time.
Given that DTN sits between two layers already in the kernel, it'd be stupid to have DTN in userspace. (Stupid and potentially dangerous, as you then have a userspace app injecting data into a fairly low level part of the kernel in a way that would have to bypass a lot of safeguards.)
As for stuff that's in the kernel that shouldn't be - want to give some examples? I can think of a few things that are probably not great, but I can't think of anything that absolutely shouldn't be there.
It sits between the Ethernet and TCP/UDP layers. Where the hell do you think it's going to sit? On top of the monitor? The only way you could add DTN except in the kernel is via netfilter (which would make this not only Linux-specific but also firewall technology specific, as netfilter is being replaced).
Adding DTN in userspace via netfilter would (a) add some very stupid and unnecessary context switches, and (b) totally subvert the purpose for which netfilter is designed, not for technical reasons but political ones.
But there's nowhere else you can put it, if you want to run DTN in userspace. Which means you either have a totally stupid, farcical solution OR a kernel implementation.
Take your pick.
...like FTP-by-email, but for any Internet protocol, not just FTP.
Until Linux and the *BSDs have DTN as standard, you're not likely to see anything serious using it. DTN could be seriously useful in a lot of circumstances, but look at the hassle getting multicasting or IPv6 - and these are protocols that have long been supported both in ISPs routers and the OS' in people's homes.
No, it doesn't break net neutrality in and of itself, any more than a traffic light or a roundabout breaks road neutrality. The idea of routing flows, rather than packets, permits more packets to get through for the same bandwidth.
So long as all flows are treated fairly, this will actually BOOST network neutrality as network companies will have less justification to throttle back protocols which take disproportionate bandwidth - as they will no longer do so. Users will also have less cause to complain, as the effective bandwidth will move closer to the theoretical bandwidth.
The only concern is if corporations and ISPs use this sort of router to discriminate against flows (ie: ensure unfair usage) rather than to improve the quality of the service (ie: ensure fair usage).
The belief by ISPs that you cannot have high throughput unless you block legitimate users is nothing more than FUD. It has no basis in reality. It is possible, by moving away from best-effort and towards fair-effort, to get higher throughput for everyone.
Congested networks can be modeled as turbulent flow in a river. Blocking streams is like damming up some of the tributary streams. It causes a lot of grief and isn't really that effective.
On the other hand, smoothing out the turbulence will improve the throughput without having to dam up anything. QoS services are intended as smoothing mechanisms, not dams. For the most part, at least.
Most "net neutrality" advocates would be advised to focus only on the efforts to build gigantic dams, rather than to be unkind or unfair on those merely smoothing the way, with no bias or discrimination intended.
No, only personal PIN numbers for identification.
Somewhere I've the circuit diagram for those in an old Wireless World. Popular in PoW camps as well as in the trenches in WW2, apparently, as they could be easily assembled, easily hidden and the parts could be smuggled in via Red Cross parcels.
If the light-sensitive components are not directional, you could have the clock emitter ABOVE the silicon on a completely independent layer. That wouldn't require them to perfect the transmission side, so could be done a lot quicker.
That's cool, but with modern chip designs using electron tunneling for some of the effects, it can't be used chip-wide. On the other hand, light can cross through light, so you would be able to avoid tediously long tracks currently required.
There may be some additional interest in the aerospace industry for this. Optical circuits on the chips aren't going to be so affected by radiation, and by having more real-estate available for redundant components and optimal placement, they can improve the resistance to radiation considerably.
Not sure how much heat this'll cut down on, as the transistors are the big heat-producers. On the other hand, better placement means more even heat production which means they should be able to push the designs a little bit further.
I'm not convinced these machines will, but the pain suffered when they are erased so publicly might result in greater investment in security.
On the other hand, users and corporations alike often rely on the "many targets, few victims" principle that says that it's only other people who are likely to be hurt.
Sad to say, short of Governments imposing minimum standards for IT security (just the same as they impose minimum standards for car safety in many countries), the best hope might actually be a major disaster, as ironic as that sounds. Sometimes, burned hands really do learn the best, as much as I hate that line of thinking.
I thought it was Irn Bru that was imported from Scotland, and that it was made of girders.
It only requires one post to get karma, right? And once someone has posted and successfully acquired karma legitimately, there's nothing further to be done and all other posts are a waste. :)
Seriously, I agree with you. The AC who started this thread is an idiot.
Not that I recall. It used an ultra-cold medium, IIRC. I think this article may be discussing the same thing. However, there seems to be other ways to reduce the speed of light to manageable levels, which is interesting.
There was a way discussed on Slashdot a while back on how to slow light to around 30 miles per hour.
Is that normal brains or shrub brains?
It was done back in the days of MUD 1 (Essex MUD). (Before anyone asks, yes, I did use the summon spell followed by the sleep spell, followed by the broadsword, quite a bit. Why do you ask?)
Lord Baden-Powell, founder of the boy scout movement, was a spy for the British Army. He encoded maps of enemy encampments as decorations on butterfly wings. Were those maps found 500 years from now with no context, they'd appear to be insects which are not known on Earth.
I'm not saying this is the case here, merely that we can't trust what we assume we know merely because the assumption looks like it might be right. If it didn't look right, it wouldn't be assumed. It doesn't make the assumption reliable.
Another example would be the Sumerian cuneiform for house. It's a tent peg. True, we know what tent pegs are, but the Sumerians had abandoned nomadic living 500-1000 years before they developed writing. If we went by what they knew, we'd never be able to reconcile what they drew with what was present.
You do realise what you've gone and done, don't you? They'll have to change the GCC acronym to mean the Gnu Creative Compiler, now.
The thing is, we know Linear A was indeed in Minoan Crete and we know a fair bit about Minoan Crete. Although we know a lot about 16th century Europe as a whole, it could be absolutely anywhere in Europe and the amount that is common across the whole of Europe back then was exceedingly small.
Ah, now I absolutely know for certain that not producing cites is mandatory on Slashdot.