Is it fair for a man who rapes a 13 year old girl walking home from school to get 1.5 years in prison, while some guy caught with cocaine for personal use gets 5 or more? Or a pot grower with a room full of bud to get 40 years no parole?
No, the laws in this country are fucked, so before you go whining about just punishment, take a look around at the major discrepancies occuring.
The problem is if/when quantum computers become available.
The computation performed by quantum computers is able to find the exact solution to a problem with many many possiblities (NP-complete for example) with a single operation.
The only contraint on the size of the problem which can be solved by quantum computers is the size of the quantum elements configured for a single operation.
Right now this is a handfull of atoms, but before long it may be enough to crack 128bit keys in a single collapse of a quantum set.
How many people here feel the moral obligations mentioned in the text? Every DMCA, RIAA, MPAA ruling seems that much closer to corporate money buying fascist control over every aspect of your interaction with intellectual property.
I hope this is a wake up call for a large portion of/. readers.
What happens when the ORB itself is part of the kernel and the entire kernel is getting beaten to death?
This is no different than a TCP SYN attack. This ties up kernel resources for allocating connection overhead (see the TCP SYN-flood protection kernel option). Quite a few DoS attacks exploit communication stack errors, which are part of the kernel.
Obviously this protocol will only serve to mask those with something to hide such as child molestors, crackers and federal building bombers.
Dear Sir,
As an agent of the federal government I am requesting entrace to your home to look around for illegal things of any type. If you do not allow me into your home, you MUST be hiding something, like child molesting, cracking, or bomb making.
The Sprint ION services run over DSL, and are starting wide rollouts in all major metropolitan cities.
While Sprint may not be a small local player aiming for some local loop action, they never the less rely on the ability to tap the local loop of the big behemoths to implement ION for customers.
There are also handfulls of third party DSL providers in most large cities, which are in the same boat.
Anyway, the article seemed a bit overboard on its interpretation of what is occuring...
These are very limited implementations and installations.
While they do work, they are not ubiquitous on the internet, and that is what I meant by QoS for IP. A complete and total QoS solution without need for special TCP/IP stacks and applications.
There seem to be a few misconceptions about the role of QoS and how it relates to direct connections (i hate the fucking E2E buzzcrap. B2B, P2P, E2E, arggg!!;)
QoS is actually used in a large portion of the backbone, but not at the IP layer.
For example, Sprint uses the same network for their digital voice (PCS, long distance). This is a big SONET backbone tied to OCx ATM networks. From there they branch to voice or data.
For IP data networks, it flies over the OCx networks just the same as voice, but voice has QoS applied to its virtual connections via ATM AAL2. IP data traffic is usually AAL5 with no QoS.
Also, many of the backbone IP providers (sprint, UUnet) use QoS/traffic shaping at the entry point for small ISP's to ensure that traffic from big fish like sprint or UUnet or AOL? gets better response.
You may remember an article about big data providers (UUnet and sprint specifically) giving crappy data service to ISP's and affecting their ability to compete or provide relaible services.
At any rate, the point of this is that currently QoS is used but internal to the backbone carriers themselves. It is definately nice to have, and allows them to implement all sorts of latency intolerant services like voice and video over their networks which cannot be implemented without QoS.
It will take a lot of effort to get QoS at the IP layer, as this will entail paying ISP's for a QoS connection, probably ATM, and running IP over that connection, or fundamentally altering the IP protocol to include QoS capabilities similar to those provided by ATM. The latter will not happen;).
Re:900Mhz / 2.4Ghz IP networks and security.
on
Open Networking
·
· Score: 2
The equivalent of war-dialing.
There are a number of channel frequencies the devices operate at (within the 2.4Ghz or 900Mhz bands).
Via software configuration you can choose one of hundreds of available 'channels' and pretend your a valid RF device.
If you can communicate at all, you have found an active channel. If not, try the next.
Proprietary devices which do not use any standard or common channel frequencies require the more expensive scanning equipment to pick out the signal.
Re:HAM radio enthusiasts have been doing it for ye
on
Open Networking
·
· Score: 2
20Mbps seems a bit high. The highest experimental setup going a few yards at best, was 10Ghz and got 2-10Mbps.
A usable network would be about 2-3 Mbps at 10Ghz to 24Ghz.
I suppose you could take a larger spread with more xpensive equipment to get up to 20Mbps, but then you get more interference. The 2.4Ghz is already polluted from the sounds of the article. Its saving grace is that it doesnt carry very far, otherwise it would be extremely dirty.
At any rate, im not an RF expert like you said, but 20Mbps still seems very optimistic with any kind of hardware.
Re:HAM radio enthusiasts have been doing it for ye
on
Open Networking
·
· Score: 2
People were still running at 9600 bps, and you had to use explicit routing ("send this to A and from there to B and from there to C...").
Actually there is a HAM group in Columbia, SC that has dynamic routing configured for their packet network.
I don't know the details, but it functions similar to an RF RIP protocol of some sort.
They may have something about this online, i'll look...
Re:HAM radio enthusiasts have been doing it for ye
on
Open Networking
·
· Score: 2
How much of this is usable for a dedicated RF transport? the 2.4Ghz band is quite large, but you cant use a 5 Mhz spread for your networking.
10Ghz microwave bands are nice for throughput, but what is the range for 10Ghz?
Re:HAM radio enthusiasts have been doing it for ye
on
Open Networking
·
· Score: 2
The benefit of sharter ranger 900Mhz or 2.4Ghz networks is bandwidth.
A typical 2.4Ghz network can handle over 1.2Mbps. Far beyond anything HAM bands can support.
While packet radio has its place, high bandwidth RF needs high frequency transport.
900Mhz / 2.4Ghz IP networks and security.
on
Open Networking
·
· Score: 5
These types of RF networks have been in use by companies for quite a few years (i.e. manufacturing data collection)
Like the TacoMan said, many of these networks aren't secured very well.
Half a dozen manufacturing plants that I integrated RF data collection devices for did not use any type of authentication of encryption and relied solely on frequency channels to identify remote RF terminals.
For a few hundred bucks, Intermec and others can provide you with ISA cards to tap into RF networks and even PCMCIA cards that you can plug right into your laptop.
These devices setup an IP connection that ties a psuedo terminal on a unix server to the ANSI/VT100/etc emulation terminal running on the data collection devices themselves.
Some of the newer models provide a light weight web browser configured for various ports on a unix server to handle the data collection interface.
Almost all (95%+) of the data collection applications that are attached to the other end of these RF terminals are running on critical enterprise servers so that they can be close to the databases they feed.
It always baffled me that the IS tech's would be so lax on security simply because it was 'RF'.
As a side note, eavesdropping on an RF network is orders of magnitude easier than typical networks (ethernet / ATM) and effectively impossible to identify. For a few hundred bucks anyone can make a RF 'tcpdump' with a laptop and RF PCMCIA card that will trap every single IP packet flying over the RF networks.
So, the moral of this story is:
RF entails much more security risk than typical networking. Beware when you implement an RF network, and keep security at the top of your to-do list.
You totally got rotating registers wrong.... They are not good because 'risc registers are small' they are good because you can make your instruction code much smaller, I.e. insted of having code that says R1=R1+R2,R2=R2+R3,R3=R3+R4.... You can say R1=R1+R4,rotate,repeat.
My appologies, I ran two points into one with that statement. The one point being rotating registers, the other being 256 registers, which is quite an increase for CISC/EPIC.
The Itanium will probably sound like another beefed up Intel chip *yawn* without much to set it apart from the crowd. (We already have lots of 64bit chips right?)
Here are a few interesting tid bits which make the Itanium something different:
- Predication. You read this part right? This means no more pipeline flushes for missed branch prediction. None. This is a big saver. Although transmetas CPU's do this (to a limited extent) with their VLIW and OS, it is still wrong on occasion (i.e., not perfect branch prediction, which itanium will effectively provide)
- Rotating registers. Why are these great? Usually you only have a few registers with CISC architectures. RISC has quite a bit more, but they are much smaller and you end up using them as much as the less populous CISC registers. Having 256 registers with the ability to cycle them means you will be hitting the L1 cache even less. While the L1 is fast, it is still at least twice as slow as hitting a register directly. This is another big bonus
- L1, L2, and L3 cache all at CPU clock speed. Most L2/L3 caches are at half speed at best.
The other enhancements, more pipelines, more ALU's, etc, are all nice but nothing ground breaking. Together with the above additions they add up to impressive performance.
The only downside with all the features is the compilers. Most of the really cool optimizations will require a compiler smart enough to translate the code effectively to ake advantage of them.
It sounds like Intel wont have a top notch compiler for another few years at best, and who knows when the GNU compiler will support even a fraction of the features.
This will be a real downer, as gcc support for Alpha's, which have been around for years and years, is still far behind digital/compaq's alpha compiler.
Interesting idea...but if I understand it correctly whatever implements the interface would still have to manually call the inner class methods, right?
Yes. Anything you want the inner class to handle would have to me forwarded to it via a method invocation. So for one operation on a concrete class, it would then perform a second invocation on its inner class to actually get the job done. Then pass back any returned value as well.
The new class must polymorphically substitute for more than one of the concrete base classes. This is extremely rare, providing you have done a good job of object modeling.
I suppose this is the root of the issue. The reason I disagree is that is impossible to ensure that you NEVER have to polymorphically substitute a new derived class for a concrete base class.
You create your concrete base class, which derives from any number of interfaces (abstract base / interface) and life is good.
Then one day, you need to extend the functionality of the base class to handle some new requirements. The other classes which operate on the base class type, are OK, and do not need to be touched.
What do you do?
aggregating the concrete base class in not an option, because your new class will not work with any of the other afore mentioned objects which operate on the concrete base class type.
You could reimplement the concrete class, inheriting from all the same interfaces, and aggregate the concrete base class, but this would be cumbersome. You would have to forward requests to your member aggregate concrete base class, and you would have to refactor any objects which previously used the concrete base class type.
If you use multiple inheritance, you simply derive from the existing concrete base, override the methods you need to customize, and your set.
You can argue that such a scenario will almost never occur, you will always use objects by interface, and not by a base class, but I disagree. You can say that good design would have prevented this, in most cases it would, but this situation will and does occur regardless.
When a scenario like this does occur, it is diffucult to solve in Java, while multiple inheritance in C++ is much easier by comparison.
Slashdot Mirror
Is it fair for a man who rapes a 13 year old girl walking home from school to get 1.5 years in prison, while some guy caught with cocaine for personal use gets 5 or more? Or a pot grower with a room full of bud to get 40 years no parole?
No, the laws in this country are fucked, so before you go whining about just punishment, take a look around at the major discrepancies occuring.
Seriously, did anyone read this before they posted it?
OOP is communistic?
No references? (Sorry, we lost them...)
A giant stinking POOP image header?
perhaps this should be under the humor category...
But it looks like the TCP/IP stack needs some work.
splat!
To bad he didnt mention what hardware it was running on...
or 2048bit public keys. (which is what we were discussing until I had a brain fart.)
The problem is if/when quantum computers become available.
The computation performed by quantum computers is able to find the exact solution to a problem with many many possiblities (NP-complete for example) with a single operation.
The only contraint on the size of the problem which can be solved by quantum computers is the size of the quantum elements configured for a single operation.
Right now this is a handfull of atoms, but before long it may be enough to crack 128bit keys in a single collapse of a quantum set.
Would be a better title for this inteview.
/. readers.
How many people here feel the moral obligations mentioned in the text? Every DMCA, RIAA, MPAA ruling seems that much closer to corporate money buying fascist control over every aspect of your interaction with intellectual property.
I hope this is a wake up call for a large portion of
What happens when the ORB itself is part of the kernel and the entire kernel is getting beaten to death?
This is no different than a TCP SYN attack. This ties up kernel resources for allocating connection overhead (see the TCP SYN-flood protection kernel option). Quite a few DoS attacks exploit communication stack errors, which are part of the kernel.
400 million base pairs.
;)
1 base pair == 2 bits of digital information in binary.
800 million bits of information == 100 million bytes.
Devide by 1024*1024 == 95 Mbytes.
Make you realize how shitty human coders are in comparison..
Obviously this protocol will only serve to mask those with something to hide such as child molestors, crackers and federal building bombers.
Dear Sir,
As an agent of the federal government I am requesting entrace to your home to look around for illegal things of any type. If you do not allow me into your home, you MUST be hiding something, like child molesting, cracking, or bomb making.
See you soon...
The Sprint ION services run over DSL, and are starting wide rollouts in all major metropolitan cities.
While Sprint may not be a small local player aiming for some local loop action, they never the less rely on the ability to tap the local loop of the big behemoths to implement ION for customers.
There are also handfulls of third party DSL providers in most large cities, which are in the same boat.
Anyway, the article seemed a bit overboard on its interpretation of what is occuring...
These are very limited implementations and installations.
While they do work, they are not ubiquitous on the internet, and that is what I meant by QoS for IP. A complete and total QoS solution without need for special TCP/IP stacks and applications.
There seem to be a few misconceptions about the role of QoS and how it relates to direct connections (i hate the fucking E2E buzzcrap. B2B, P2P, E2E, arggg!! ;)
;).
QoS is actually used in a large portion of the backbone, but not at the IP layer.
For example, Sprint uses the same network for their digital voice (PCS, long distance). This is a big SONET backbone tied to OCx ATM networks. From there they branch to voice or data.
For IP data networks, it flies over the OCx networks just the same as voice, but voice has QoS applied to its virtual connections via ATM AAL2. IP data traffic is usually AAL5 with no QoS.
Also, many of the backbone IP providers (sprint, UUnet) use QoS/traffic shaping at the entry point for small ISP's to ensure that traffic from big fish like sprint or UUnet or AOL? gets better response.
You may remember an article about big data providers (UUnet and sprint specifically) giving crappy data service to ISP's and affecting their ability to compete or provide relaible services.
At any rate, the point of this is that currently QoS is used but internal to the backbone carriers themselves. It is definately nice to have, and allows them to implement all sorts of latency intolerant services like voice and video over their networks which cannot be implemented without QoS.
It will take a lot of effort to get QoS at the IP layer, as this will entail paying ISP's for a QoS connection, probably ATM, and running IP over that connection, or fundamentally altering the IP protocol to include QoS capabilities similar to those provided by ATM. The latter will not happen
The equivalent of war-dialing.
There are a number of channel frequencies the devices operate at (within the 2.4Ghz or 900Mhz bands).
Via software configuration you can choose one of hundreds of available 'channels' and pretend your a valid RF device.
If you can communicate at all, you have found an active channel. If not, try the next.
Proprietary devices which do not use any standard or common channel frequencies require the more expensive scanning equipment to pick out the signal.
20Mbps seems a bit high. The highest experimental setup going a few yards at best, was 10Ghz and got 2-10Mbps.
A usable network would be about 2-3 Mbps at 10Ghz to 24Ghz.
I suppose you could take a larger spread with more xpensive equipment to get up to 20Mbps, but then you get more interference. The 2.4Ghz is already polluted from the sounds of the article. Its saving grace is that it doesnt carry very far, otherwise it would be extremely dirty.
At any rate, im not an RF expert like you said, but 20Mbps still seems very optimistic with any kind of hardware.
People were still running at 9600 bps, and you had to use explicit routing ("send this to A and from there to B and from there to C ...").
Actually there is a HAM group in Columbia, SC that has dynamic routing configured for their packet network.
I don't know the details, but it functions similar to an RF RIP protocol of some sort.
They may have something about this online, i'll look...
How much of this is usable for a dedicated RF transport? the 2.4Ghz band is quite large, but you cant use a 5 Mhz spread for your networking.
10Ghz microwave bands are nice for throughput, but what is the range for 10Ghz?
The benefit of sharter ranger 900Mhz or 2.4Ghz networks is bandwidth.
A typical 2.4Ghz network can handle over 1.2Mbps. Far beyond anything HAM bands can support.
While packet radio has its place, high bandwidth RF needs high frequency transport.
These types of RF networks have been in use by companies for quite a few years (i.e. manufacturing data collection)
Like the TacoMan said, many of these networks aren't secured very well.
Half a dozen manufacturing plants that I integrated RF data collection devices for did not use any type of authentication of encryption and relied solely on frequency channels to identify remote RF terminals.
For a few hundred bucks, Intermec and others can provide you with ISA cards to tap into RF networks and even PCMCIA cards that you can plug right into your laptop.
These devices setup an IP connection that ties a psuedo terminal on a unix server to the ANSI/VT100/etc emulation terminal running on the data collection devices themselves.
Some of the newer models provide a light weight web browser configured for various ports on a unix server to handle the data collection interface.
Almost all (95%+) of the data collection applications that are attached to the other end of these RF terminals are running on critical enterprise servers so that they can be close to the databases they feed.
It always baffled me that the IS tech's would be so lax on security simply because it was 'RF'.
As a side note, eavesdropping on an RF network is orders of magnitude easier than typical networks (ethernet / ATM) and effectively impossible to identify. For a few hundred bucks anyone can make a RF 'tcpdump' with a laptop and RF PCMCIA card that will trap every single IP packet flying over the RF networks.
So, the moral of this story is:
RF entails much more security risk than typical networking. Beware when you implement an RF network, and keep security at the top of your to-do list.
You totally got rotating registers wrong. ... They are not good because 'risc registers are small' they are good because you can make your instruction code much smaller, I.e. insted of having code that says R1=R1+R2,R2=R2+R3,R3=R3+R4.... You can say R1=R1+R4,rotate,repeat.
My appologies, I ran two points into one with that statement. The one point being rotating registers, the other being 256 registers, which is quite an increase for CISC/EPIC.
The article and many posts mention internet based collaboration as the main replacement for groups like the XCF.
Are there any groups online that are more than a simple sourceforge project and mailing list? Do any such groups for development exist online?
It remains to be seen if IA64 can really have that much physical memory.
While the capability may be there, I don't think it will happen before the chip is completely obsolete.
64bit address space > 16,777,216 Terabytes of memory.
The Itanium will probably sound like another beefed up Intel chip *yawn* without much to set it apart from the crowd. (We already have lots of 64bit chips right?)
Here are a few interesting tid bits which make the Itanium something different:
- Predication. You read this part right? This means no more pipeline flushes for missed branch prediction. None. This is a big saver. Although transmetas CPU's do this (to a limited extent) with their VLIW and OS, it is still wrong on occasion (i.e., not perfect branch prediction, which itanium will effectively provide)
- Rotating registers. Why are these great? Usually you only have a few registers with CISC architectures. RISC has quite a bit more, but they are much smaller and you end up using them as much as the less populous CISC registers. Having 256 registers with the ability to cycle them means you will be hitting the L1 cache even less. While the L1 is fast, it is still at least twice as slow as hitting a register directly. This is another big bonus
- L1, L2, and L3 cache all at CPU clock speed. Most L2/L3 caches are at half speed at best.
The other enhancements, more pipelines, more ALU's, etc, are all nice but nothing ground breaking. Together with the above additions they add up to impressive performance.
The only downside with all the features is the compilers. Most of the really cool optimizations will require a compiler smart enough to translate the code effectively to ake advantage of them.
It sounds like Intel wont have a top notch compiler for another few years at best, and who knows when the GNU compiler will support even a fraction of the features.
This will be a real downer, as gcc support for Alpha's, which have been around for years and years, is still far behind digital/compaq's alpha compiler.
Interesting idea...but if I understand it correctly whatever implements the interface would still have to manually call the inner class methods, right?
Yes. Anything you want the inner class to handle would have to me forwarded to it via a method invocation. So for one operation on a concrete class, it would then perform a second invocation on its inner class to actually get the job done. Then pass back any returned value as well.
The new class must polymorphically substitute for more than one of the concrete base classes. This is extremely rare, providing you have done a good job of object modeling.
I suppose this is the root of the issue. The reason I disagree is that is impossible to ensure that you NEVER have to polymorphically substitute a new derived class for a concrete base class.
You create your concrete base class, which derives from any number of interfaces (abstract base / interface) and life is good.
Then one day, you need to extend the functionality of the base class to handle some new requirements. The other classes which operate on the base class type, are OK, and do not need to be touched.
What do you do?
aggregating the concrete base class in not an option, because your new class will not work with any of the other afore mentioned objects which operate on the concrete base class type.
You could reimplement the concrete class, inheriting from all the same interfaces, and aggregate the concrete base class, but this would be cumbersome. You would have to forward requests to your member aggregate concrete base class, and you would have to refactor any objects which previously used the concrete base class type.
If you use multiple inheritance, you simply derive from the existing concrete base, override the methods you need to customize, and your set.
You can argue that such a scenario will almost never occur, you will always use objects by interface, and not by a base class, but I disagree. You can say that good design would have prevented this, in most cases it would, but this situation will and does occur regardless.
When a scenario like this does occur, it is diffucult to solve in Java, while multiple inheritance in C++ is much easier by comparison.
Java never was about peak performance. Its strong points are platform independance and usability.
Speed is only one factor in determining the quality of a language or library.
While java threads are not the fastest, I think they are the easiest, and most usefull threading in any language I have seen sofar.