You should read the link you posted - it describes that sr-90 as a significant health problem.
I don't understand the point you are trying to make about us being all dead - most of us aren't exposed to it in any significant quantity (because people realise how what awful stuff it is). Besides, sr-90 won't kill you in days, just condemn you to cancer (mainly leukemia) in later life.
You are such a stereotypical clueless Slashdot user. - speaking with a sense of authority, berating people who disagree while making utterly incorrect assertions.
If you had done *any* research, you would quickly see that Strontium-90 is a *major* problem. Not because of the type of radiation it emits, but because of its bio-uptake and subsequent incorporation into bone material in place of calcuim. It then sits in bones, irradiating bone marrow and surrounding tissue for the rest of the poor subject's life.
The SPEWS level 2 list is pretty agressive, so much so that I can't imagine it being used for blocking by commercial operations of any significant size. Individuals are another matter - do you really want to make a fuss over a few people who don't want to receive your mail?
That being said, netblocks get listed for a reason. SPEWS does a pretty good job at providing a history of abuse. If this proves to be true, then you should choose a different provider - I wouldn't want my money going to someone supportive of spam operations.
Companies like Microsoft don't need help to break standards, they are more than capable of doing it on their own. In fact the SFU example demonstrates the exact opposite: the code was available, it was adopted in a compatible manner, the license was followed and the result was good for everyone.
If anything, the existence of code in a incompatible license is going to increase the likelihood of deranged implementation. If they already have to reimplement it because they are unwilling to put up with GPL code in their product, then they are just as likely to implement all the features that they want while they are there (and standards be damned).
An interesting aside - someone from a company that offers commercial Windows interop tools has already has posted patches to build OpenSSH under Interix SFU. So please don't tell me that the BSD license equates to wasted effort and closed derivates.
I'm quite happy for anyone to use the code I have released under BSD licenses. I'd love it if Microsoft included a port of OpenSSH with their operating system, just as I am happy that they are releasing some POSIXy tools (mostly based on BSD licensed code).
This has already happened - Sun's Solaris 9 SSH is based on portable OpenSSH. I'm happy that Solaris is a little less braindamaged out of the box these days (though I wish they would get a modern/bin/sh).
Would I care if Microsoft were to make a few $$$ of my work? Not at all - I have lost nothing by their gain. The original, free code would still be out there for people to improve and every additional line of 3rd-party free code that these proprietary software companies have to track puts them closer to that pain threshold where they decide it is easier to contribute their changes back to the community than maintain their own forked version.
You are confusing steganography and watermarking. Related, but not identical. In fact, they are usually worlds apart in intent. E.g. A terrorist cell wouldn't give a rats arse about robustly encoding their messagein the pictures they post to alt.pictures.women.taliban, but would want its presence in the media stream to be statistically undetectible. Read up on the property of "deniability" when you are doing trying to throw your intellectual weight around.
BTW I never said "hide it in the LSB", I said "hide it below the noise floor". If you really did a "graduation thesis" (whatever that is, undergrad perhaps?) on the subject, then I'd expect you to appreciate the difference between the two concepts.
It is trivial to write a program to discover content that has been stegged. A jpeg with hidden content would be quite easy to find if the areas with content where significantly different from those without.
The point of steganography is to hide information so that its presence cannot be detected. This means hiding information below the noise floor of the media. Information hidden in this way cannot be practically detected, assuming the stego is halfway decent, and the message to be hidden appears random (easily accomplished by encrypting it first).
Sure, *if* you had access to the unaltered original, then you could detect that it had been altered, but any competent steganographer would encrypt the hidden information first.
It would be possible with time and processing power to dicover what bits where stegged if you used/dev/urandom to get the data.
This sentence demonstrates that you don't understand either/dev/urandom or steganography.
Knowing your processor type and kernel implientation the powers that be could find patterns in the data and look for those (or absence of those) in your message. But if the randomness is of a natural type then the difficulty increases by a massive amount.
More mis-informed rubbish - kernel implementation and processor type have little to do with the algorithms underlying the/dev/urandom implementation. Furthermore,/dev/urandom is based on "natural type" entropy (i.e randomness derived from unpredicable physical processes).
So if you have to hide something from the feds then become a scientist and collect lots of data from nature. It should have an element of randomness that allows you to steg your secrets in the data.
or, you could go and take a regular photo. Plenty of real, nature-derived randomess there.
The point of the new GTK+ file selector is not so much how it looks than the fact that it is based around a new, extensible API. The old implementation was so tied to the API that its appearance couldn't really be altered (on a system-wide level), the new file selector can.
I'm sorry, but many networks use CBQ for traffic engineering because, at the edge, most people are bandwidth constrained. How on earth do you engineer surplus bandwidth in the age of KaZaa without QoS?
Even at the core some basic QoS is necessary on CSMA/CD media, lest a bunch of 1500 byte FTP packets preempt your jitter-sensitive multimedia traffic. Throwing bandwidth doesn't solve that problem, it only mitigates it. Furthermore the improvement that you do get is sublinear with the additional of bandwidth, while bandwidth costs ($/Mbps) are superlinear. Sure it'll work, up to a point, but piping gigabit to the home just to make VoIP calls work while I'm downloading with BitTorrent isn't going to happend
In the Internet, simplicity has won.
That sounds really nice as a soundbite, but that doesn't make it true.
QoS is far from being a dud - it is a critical part of any VoIP deployment and is now a part of any substantial core network engineering. QoS brokering between ASs (e.g. RSVP) has been a dud so far, but interdomain VoIP is still pretty young so there hasn't been much demand.
What about architecture changes that have worked? IPsec, ECN, CIDR (and the many changes that came from that, e.g. BGP4) and MPLS? It is too easy to focus on things that failed and ignore the things the silently work.
The BBC and Sinclair computers were very popular in Australia too, with many schools purchasing the BBCs in particular. I had a BBC B as my first computer. It was a wonderful way to learn about computers - an excellent semi-procedural basic (GOSUB was new back then), a 6502 assembler built into the basic interpreter, a decent sound chip and OKish graphics.
It sounds like a traditional signature-matching IDS with most of it implemented on a FPGA. This isn't such a big deal - it won't "stop malware before it hits" because signatures still need to be installed on the device. An implementation on a FPGA is great for speed - which would make this device great for mitigating worm attacks, but the FPGA may constrain its utility as an IDS - it would probably lack capacity to perform some of the trickier IDS techniques (e.g. looking inside compressed or encoded content, traffic normalisation, etc.) The linked article was little more than a marketing blurb, so its hard to tell.
You have just guaranteed that I will never buy one of your products. Furthermore I'll make sure I tell anyone I know who is interested in consumer gear of your utterly slimy behaviour along with my recommendation to give you a wide bearth.
"We have decided to get out of the home desktop market, so no one should use linux on the desktop any more."
Are you trolling or just deliberately ignorant? That is a completely inaccurate and misleading characterisation of what Szulik said.
Anyone who reads the article would see "We think that the enterprise desktop market place is much more strategic and has buyers whose needs we can exceed." So no, RedHat is not abandoning the desktop market, or recommending that people don't use other distributions, just realisticly stating that if consumers expect home Linux to be as easy as XP, then they will be disappointed.
Fortunately the X protocol can be extended without being replaced. OpenGL (GLX actually), Xrender, XVideo and the XSHM (the shared memory extension) are all examples of extensions that have been added without breaking old apps. Parts of X may be crusty, but overall it is pretty well designed.
XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.
Note thst strcpy() and friends _can_ be used safely, and the usage of the ones in the tree before the removal had been audited at least once. For example, the following construct is safe (assuming you check the malloc return):
len = strlen(foo) + 1;
bar = malloc(len);
strcpy(bar, foo);
But is was easier to just banish them from the tree entirely, so that it is easier to grep for potentially unsafe ones when new code is imported.
The end pretty much happened earlier this year when the most talented and prolific developers forked to form the xouvert
Rubbish - the Xouvert website lists *no* developers from XFree and the mailing list has less than 30 messages on it for this month (compare with the XFree mailing list traffic). I'd say the end is yet to come (though XFree does have some leadership problems)
If they had started with code rather than a slightly silly name, then perhaps they would have done better.
Say what you want about Bush killing jobs, it doesn't even compare with the French enforcing a 35-hour max workweek.
You do realise that the purpose of an enforced 35-hour work week is to create more jobs? The concept is simple: share the same workload over more workers. For that purpose, it makes more sense than a bunch of tax cuts. Especially dividend tax cuts, which encourage shareholders to pull more profit out of their holdings (as opposed to taking it as capital growth). Such profit maximisation is usually done by *cutting* jobs.
Slashdot Mirror
You should read the link you posted - it describes that sr-90 as a significant health problem. I don't understand the point you are trying to make about us being all dead - most of us aren't exposed to it in any significant quantity (because people realise how what awful stuff it is). Besides, sr-90 won't kill you in days, just condemn you to cancer (mainly leukemia) in later life.
You are such a stereotypical clueless Slashdot user. - speaking with a sense of authority, berating people who disagree while making utterly incorrect assertions.
If you had done *any* research, you would quickly see that Strontium-90 is a *major* problem. Not because of the type of radiation it emits, but because of its bio-uptake and subsequent incorporation into bone material in place of calcuim. It then sits in bones, irradiating bone marrow and surrounding tissue for the rest of the poor subject's life.
Get a clue before shooting your mouth off.
The SPEWS level 2 list is pretty agressive, so much so that I can't imagine it being used for blocking by commercial operations of any significant size. Individuals are another matter - do you really want to make a fuss over a few people who don't want to receive your mail?
That being said, netblocks get listed for a reason. SPEWS does a pretty good job at providing a history of abuse. If this proves to be true, then you should choose a different provider - I wouldn't want my money going to someone supportive of spam operations.
Companies like Microsoft don't need help to break standards, they are more than capable of doing it on their own. In fact the SFU example demonstrates the exact opposite: the code was available, it was adopted in a compatible manner, the license was followed and the result was good for everyone.
If anything, the existence of code in a incompatible license is going to increase the likelihood of deranged implementation. If they already have to reimplement it because they are unwilling to put up with GPL code in their product, then they are just as likely to implement all the features that they want while they are there (and standards be damned).
An interesting aside - someone from a company that offers commercial Windows interop tools has already has posted patches to build OpenSSH under Interix SFU. So please don't tell me that the BSD license equates to wasted effort and closed derivates.
I'm quite happy for anyone to use the code I have released under BSD licenses. I'd love it if Microsoft included a port of OpenSSH with their operating system, just as I am happy that they are releasing some POSIXy tools (mostly based on BSD licensed code).
/bin/sh).
This has already happened - Sun's Solaris 9 SSH is based on portable OpenSSH. I'm happy that Solaris is a little less braindamaged out of the box these days (though I wish they would get a modern
Would I care if Microsoft were to make a few $$$ of my work? Not at all - I have lost nothing by their gain. The original, free code would still be out there for people to improve and every additional line of 3rd-party free code that these proprietary software companies have to track puts them closer to that pain threshold where they decide it is easier to contribute their changes back to the community than maintain their own forked version.
You mean "looks like they are using X" - it could easuly be BSD, Solaris or any other Unix-like OS.
No, it's not just you. Most of the world seems to agree.
You are confusing steganography and watermarking. Related, but not identical. In fact, they are usually worlds apart in intent. E.g. A terrorist cell wouldn't give a rats arse about robustly encoding their messagein the pictures they post to alt.pictures.women.taliban, but would want its presence in the media stream to be statistically undetectible. Read up on the property of "deniability" when you are doing trying to throw your intellectual weight around.
BTW I never said "hide it in the LSB", I said "hide it below the noise floor". If you really did a "graduation thesis" (whatever that is, undergrad perhaps?) on the subject, then I'd expect you to appreciate the difference between the two concepts.
The point of steganography is to hide information so that its presence cannot be detected. This means hiding information below the noise floor of the media. Information hidden in this way cannot be practically detected, assuming the stego is halfway decent, and the message to be hidden appears random (easily accomplished by encrypting it first).
Sure, *if* you had access to the unaltered original, then you could detect that it had been altered, but any competent steganographer would encrypt the hidden information first.
This sentence demonstrates that you don't understand either /dev/urandom or steganography.
More mis-informed rubbish - kernel implementation and processor type have little to do with the algorithms underlying the /dev/urandom implementation. Furthermore, /dev/urandom is based on "natural type" entropy (i.e randomness derived from unpredicable physical processes).
So if you have to hide something from the feds then become a scientist and collect lots of data from nature. It should have an element of randomness that allows you to steg your secrets in the data.or, you could go and take a regular photo. Plenty of real, nature-derived randomess there.
It is just as easy to enshrine bad design in objects as it is in functions. Gtk+ has fairly object-oriented anyway.
The point of the new GTK+ file selector is not so much how it looks than the fact that it is based around a new, extensible API. The old implementation was so tied to the API that its appearance couldn't really be altered (on a system-wide level), the new file selector can.
I'm sorry, but many networks use CBQ for traffic engineering because, at the edge, most people are bandwidth constrained. How on earth do you engineer surplus bandwidth in the age of KaZaa without QoS?
Even at the core some basic QoS is necessary on CSMA/CD media, lest a bunch of 1500 byte FTP packets preempt your jitter-sensitive multimedia traffic. Throwing bandwidth doesn't solve that problem, it only mitigates it. Furthermore the improvement that you do get is sublinear with the additional of bandwidth, while bandwidth costs ($/Mbps) are superlinear. Sure it'll work, up to a point, but piping gigabit to the home just to make VoIP calls work while I'm downloading with BitTorrent isn't going to happend
In the Internet, simplicity has won.
That sounds really nice as a soundbite, but that doesn't make it true.
QoS is far from being a dud - it is a critical part of any VoIP deployment and is now a part of any substantial core network engineering. QoS brokering between ASs (e.g. RSVP) has been a dud so far, but interdomain VoIP is still pretty young so there hasn't been much demand.
What about architecture changes that have worked? IPsec, ECN, CIDR (and the many changes that came from that, e.g. BGP4) and MPLS? It is too easy to focus on things that failed and ignore the things the silently work.
QED
The BBC and Sinclair computers were very popular in Australia too, with many schools purchasing the BBCs in particular. I had a BBC B as my first computer. It was a wonderful way to learn about computers - an excellent semi-procedural basic (GOSUB was new back then), a 6502 assembler built into the basic interpreter, a decent sound chip and OKish graphics.
It sounds like a traditional signature-matching IDS with most of it implemented on a FPGA. This isn't such a big deal - it won't "stop malware before it hits" because signatures still need to be installed on the device. An implementation on a FPGA is great for speed - which would make this device great for mitigating worm attacks, but the FPGA may constrain its utility as an IDS - it would probably lack capacity to perform some of the trickier IDS techniques (e.g. looking inside compressed or encoded content, traffic normalisation, etc.) The linked article was little more than a marketing blurb, so its hard to tell.
You have just guaranteed that I will never buy one of your products. Furthermore I'll make sure I tell anyone I know who is interested in consumer gear of your utterly slimy behaviour along with my recommendation to give you a wide bearth.
Are you trolling or just deliberately ignorant? That is a completely inaccurate and misleading characterisation of what Szulik said.
Anyone who reads the article would see "We think that the enterprise desktop market place is much more strategic and has buyers whose needs we can exceed." So no, RedHat is not abandoning the desktop market, or recommending that people don't use other distributions, just realisticly stating that if consumers expect home Linux to be as easy as XP, then they will be disappointed.
Fortunately the X protocol can be extended without being replaced. OpenGL (GLX actually), Xrender, XVideo and the XSHM (the shared memory extension) are all examples of extensions that have been added without breaking old apps. Parts of X may be crusty, but overall it is pretty well designed.
XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.
You are right, but you can use width specifiers, e.g. sprintf(bar, "(%.10s)\n", foo);
Note thst strcpy() and friends _can_ be used safely, and the usage of the ones in the tree before the removal had been audited at least once. For example, the following construct is safe (assuming you check the malloc return):
len = strlen(foo) + 1;bar = malloc(len);
strcpy(bar, foo);
But is was easier to just banish them from the tree entirely, so that it is easier to grep for potentially unsafe ones when new code is imported.
So? He isn't listed as a developer and isn't active on the mailing list.
Rubbish - the Xouvert website lists *no* developers from XFree and the mailing list has less than 30 messages on it for this month (compare with the XFree mailing list traffic). I'd say the end is yet to come (though XFree does have some leadership problems)
If they had started with code rather than a slightly silly name, then perhaps they would have done better.
You do realise that the purpose of an enforced 35-hour work week is to create more jobs? The concept is simple: share the same workload over more workers. For that purpose, it makes more sense than a bunch of tax cuts. Especially dividend tax cuts, which encourage shareholders to pull more profit out of their holdings (as opposed to taking it as capital growth). Such profit maximisation is usually done by *cutting* jobs.
Rubbish. Research papers aren't filled with invective and editorialising.