Let me get this straight...Oracle is helping to make an "Unbreakable Linux"?
Yeah. its so you can run their Unhackable Oracle database; presumably abord the Unsinkable Titanic - whatever happened to that anyhow?
........
For the benefit of anyone from Ford Prefect's planet - the above is sarcasm.
I would have thought short term cachflow problems would imply a long term profitability problem. It implies that they can't get a bank loan, and can't even get any investors, having already spent all the money the other foolhardy investors dumped in their venture.
Depends on the nature of the problem.
I know at least one company that had to move their wage payment date by a week (from first working day of the month to same plus a week) because, while money coming in to pay for work done was more than enough to cover money going out as wages (plus management wages and management bonuses and... well you get the idea) a customer going bust left them without enough float to pay all the overheads, wages and so forth until the payment for the previous month's work cleared the bank - which of course takes a week.
Needless to say, the people actually earning this money were a little put out to find this out a week or so before it went into effect, particuarly given the number of bills, direct debits and so forth that there wouldn't be sufficent funds in their bank to meet..... but as far as I know, the company has recovered from that hiccup and is doing nicely - but still hasn't put the wages back to the first of the month, so I have no idea what will happen if the situation comes up again.
Not sure that is true - if you refuse to take the pay cut (and jump ship) you can sue for your back pay, and probably for unused vacation time (unless you use that in leu of notice)
I would be deeply frightened about any contract of employment that doesnt' bind the company to pay your current agreed pay rate unless you accept otherwise.
A fifty percent pay cut says, "We know many of you will quit because of this horrendous abuse we are imposing on our employees, and to us, this is good, because if we just fired you, we'd have to pay unemployment benefits"
Problem is - about 50% of the employees will probably get better offers elsewhere (even with the lower average wage since this time last year, there are still good jobs out there for those with the right skillset) and the remainder will be those who can't get a better offer than they are on now - which probably means they aren't worth what they are currently being paid in a free market.
How this can be good for even medium-term company survival escapes me....
Re:Saw something similar about EULAs in general
on
GPL's Strength
·
· Score: 2
I suspect you could "fall back" to a standard purchase contract if you bought a boxed copy of Redhat without agreeing to the GPL - ie, you have a single copy for use within fair use right limitations, including first purchase (so you could sell the complete package or functionally separate parts of the package on for any amount you like, provided you don't retain a copy) but only acceptance of the GPL will allow you to sell or give away a copy, or distribute derived works (altered copies)
One effect that *does* occur to me - while the actual source of the changes made by Y to X's code are GPLed, any IP in the changes is also owned by Y (and licenced under GPL). As a side effect, presumably not only would X have to reproduce the effect of Y's patches if the new closed source release is to have the same abilities, he would have to show that he either came up with the ideas incorporated in Y's patches independently, or that they would have been obvious to anyone approaching the problem (the usual IP stuff).
obviously, IANAL, so if anyone wants to take a stab at answering this one..
The bit I am curious about is - if Mosix were GPL, and presumably contributed to by various of the now OpenMosix researchers, how did it become closed?
I have found This link, but that suggests a code fork rather than a revival-after-closing-source.
The obvious reply to this is - if it is protection by deliberate error, then the disk (by definition) contains errors so isn't of merchantable quality. They can hardly claim that it doesn't contain errors (or that they didn't know about them) if they deliberately put them there in the first place.
I would have thought this would have opened a can of worms that your employer would have preferred kept shut - there is nothing preventing you (by that criteria) taking a full copy of their part of the source, re-obfusc-ing it so that it is superficially different from their version, then releasing it as a competing product. given it hasn't cost you any developer wages, you should make a fortune undercutting your employer... its even file-format compatable with theirs;)
Agreed - much of the layout on the Vectra series cases should be junked and started over. The Vectra VL tower however is very nicely laid out indeed - makes swapping components in and out a breeze - but is so designed around the custom motherboard that replacing the motherboard can be a nightmare.
Some do. The Vectras are basically the same motherboard and other internal components (you lose the remote management stuff, but most companies don't bother with that anyhow, having bought a solution from Microsoft or Novell)
If a pavilion is noticiably cheaper, then it makes sense to go for it - particularly if you are buying two or three hundred at a time.
Not sure what the requirements here are - but it seems you are more concerned with correctly authenticating a command to the satellite than concealing the content of the commands.
If that is the case, then you really only need to change the format slightly to include timestamped (or sequentially numbered), signed messages rather than unauthenticated ones (timestamps to prevent simple retransmission of commands as a "cut and paste" control system). There are plenty of PK signature solutions out there - but I assume uploading a new program may be a problem - debugging would be a nightmare;)
I dunno if I'd ever advise anyone to allow their keys to be stored on the server, no matter how many reassurances they get. However, for someone who simply wishes to share private mail with someone else, it might be nice.
not entirely a bad thing - the security of the PGP secret keyring does not require secrecy of the file - if you really want it, I will mail you a copy - but *does* require that the key be encrypted and that a good, unguessable passphrase be used.
The base model seems to be the same as Hushmails (with the one exception of an option to store the key locally; hushmail doesn't have that)
at least at first glance, it looks good - actual encryption model is very pgplike, with public keys protecting session keys protecting messages via symmetric encryption; however, even Hushmail has realised that OpenPGP compatability is the way to go, and has set up a site to allow PGP users to import their DH public keys to Hushmail (for use by hushmail users) and export their hushmail keys for upload to keyservers.
With the inclusion of file storage into the pot, it looks like an attempt to take the Hushmail business model and run with it - but unless they move towards OpenPGP compatiability, they will almost certainly lose the interoperability war, and with it a lot of potential users.
You aren't forced to use the built-in keyboard - there is a handwriting recognition mode, a onscreen keyboard (pc layout) or a character picker (letter groups similar to mobile phone, but a little easier to use)
the built in keyboard takes quite a bit of getting used to, but you can get up to quite a respectiable typing speed with it, holding the device in both hands and "thumb typing".
Thanks for that - I have just got a DC second hand, and was looking for info on programming it.
now have two keyboard/mouse adaptors and a serial cable ordered and on their way, and the rereqs for the linux CD are downloading now:)
As far as I can tell, yes - even the program itself (scramdisk) can't tell if a scramdisk file really is a scramdisk file unless it tries to decrypt it with the right password.
I am not aware of any reasonable way to statistically distinguish (for example) a 3DES encrypted block from random noise (and a quick websearch didn't enlighten me any further) - Steganographic packages *can* be statistically detected, for two reasons:
First, many don't use crypto at all, and/or have predictable header structures
Second, most use Jpg files for storage, which (due to the lossy compression) then differ from how the image would normally have been compressed (the line transitions are not as smooth as they should be). I don't exactly follow how you detect that programatically, but it is often visible when you compare a before and after.
yes, completely. Hold on, I will read back a bit and try and figure how why we are both arguing the same points:)
*mumble mumble*
Hmm. the original statement I was disagreeing with was that use of unbackdoored crypto would be "easily spotted". I was making the point that it would be hard to spot even non-steganographic crypto unless you deliberately decrypted and exhaustively examined every email sent by anyone (which would be both a massive invasion of privacy, and technically impossible with today's tech)
ah - you *do* realise that Scramdisk steganographic data is encrypted, and therefore is statistically random, yes?
There is also no unencrypted static header data in a scramdisk - purposely to make it impossible to prove a given random stream is a SD and not a keypad for OTP.
I tried this a couple of years back - the lower four bits of a noisy sound sample seem pretty random, to the point where I actually use the lower bits of a sound sample from a noisy source (samples of a radio reciever via a soundcard) as a medium-grade entropy source. I did quite a few conversions, self-pattern matching exercises and FFTs and couldn't find any patterns worth a damn. feel free to try it yourself - as I say, I am actually using this method to generate entropy for crypto, so if it is insecure I would appreciate knowing about it..
Normally, such laws are proposed as "we will retain the right to read your email, but don't worry, we won't actually do so unless you are under investigation"
This works fine if everyone is forced to use the indicated (legal) protection and no better, but in practice, someone can wrapper the illegal stuff with the legal, and nobody will know unless that message (and therefore every message) is checked.
as an analogy - imagine that the USG wanted it to be illegal for the trunk (is that the american term?) of a car to be opaque as leas needed to be able to see what you were carrying in there, so they order that every car must have a little window on the top of the lid of the trunk so that LEA officers can look in if they need to.
however, you could always put an opaque box IN the trunk, and they wouldn't know unless they looked, so the only solution is to have cameras above the roads looking down into EVERY trunk so that they can check for opaque boxes, and just incidentally had better look inside the passenger compartment too, just in case you tried to sneek an opaque box past them there...
Yup, there are probably thousands of cases where they can't go ahead and prosecute because there is no evidence beyond the intercept data, and that data is "tainted" by having been gathered illegally.
Not a good reason to retroactively authorise it though.
Obvious answer to this one - download a (free) copy and try it.
for four bit, I can't hear it at all when playback is via computer speakers or headphones (obviously, not the superior quality hi-fi headphones a music lover would own, but then the soundcard is only a 64 bit soundblaster anyhow) even in very quiet sections of the music.
with the secondary 8 bit method, I *can* hear a noticable hiss, but no more than you would get from a poor quality recording from the radio.
as I said, the key is to not use a "prefect" digital sample to begin with - certainly, for samples recorded via a sound card I have heard worse than the output of the 8 bit mode......
no, because unless you perform 100% monitoring (decrypt every message and look inside it) you don't know if the "authorized" backdoored encryption packet is only an outer wrapper around a PGP message.
The same goes for messages *not* apparently using encryption of course - because if they are ascii armoured pgp, file attachments, zipfiles (possibly password protected), executables or any other of a hundred different things, they *might* have crypto inside them.
The argument of key security is another of course (the big flaw in key escrow is how valuable the escrow database would be; a single corporate key from that database could literally be beyond price, and there would be thousands of them in there)
Slashdot Mirror
Yeah. its so you can run their Unhackable Oracle database; presumably abord the Unsinkable Titanic - whatever happened to that anyhow?
For the benefit of anyone from Ford Prefect's planet - the above is sarcasm.
I would have thought short term cachflow problems would imply a long term profitability problem. It implies that they can't get a bank loan, and can't even get any investors, having already spent all the money the other foolhardy investors dumped in their venture.
Depends on the nature of the problem.
I know at least one company that had to move their wage payment date by a week (from first working day of the month to same plus a week) because, while money coming in to pay for work done was more than enough to cover money going out as wages (plus management wages and management bonuses and... well you get the idea) a customer going bust left them without enough float to pay all the overheads, wages and so forth until the payment for the previous month's work cleared the bank - which of course takes a week.
Needless to say, the people actually earning this money were a little put out to find this out a week or so before it went into effect, particuarly given the number of bills, direct debits and so forth that there wouldn't be sufficent funds in their bank to meet..... but as far as I know, the company has recovered from that hiccup and is doing nicely - but still hasn't put the wages back to the first of the month, so I have no idea what will happen if the situation comes up again.
Not sure that is true - if you refuse to take the pay cut (and jump ship) you can sue for your back pay, and probably for unused vacation time (unless you use that in leu of notice)
I would be deeply frightened about any contract of employment that doesnt' bind the company to pay your current agreed pay rate unless you accept otherwise.
A fifty percent pay cut says, "We know many of you will quit because of this horrendous abuse we are imposing on our employees, and to us, this is good, because if we just fired you, we'd have to pay unemployment benefits"
Problem is - about 50% of the employees will probably get better offers elsewhere (even with the lower average wage since this time last year, there are still good jobs out there for those with the right skillset) and the remainder will be those who can't get a better offer than they are on now - which probably means they aren't worth what they are currently being paid in a free market.
How this can be good for even medium-term company survival escapes me....
I suspect you could "fall back" to a standard purchase contract if you bought a boxed copy of Redhat without agreeing to the GPL - ie, you have a single copy for use within fair use right limitations, including first purchase (so you could sell the complete package or functionally separate parts of the package on for any amount you like, provided you don't retain a copy) but only acceptance of the GPL will allow you to sell or give away a copy, or distribute derived works (altered copies)
obviously, IANAL, so if anyone wants to take a stab at answering this one..
The bit I am curious about is - if Mosix were GPL, and presumably contributed to by various of the now OpenMosix researchers, how did it become closed?
I have found This link, but that suggests a code fork rather than a revival-after-closing-source.
you can make one yourself semi-trivially by taking a standard D20 and striking out the high digit whenever present :)
The obvious reply to this is - if it is protection by deliberate error, then the disk (by definition) contains errors so isn't of merchantable quality. They can hardly claim that it doesn't contain errors (or that they didn't know about them) if they deliberately put them there in the first place.
I would have thought this would have opened a can of worms that your employer would have preferred kept shut - there is nothing preventing you (by that criteria) taking a full copy of their part of the source, re-obfusc-ing it so that it is superficially different from their version, then releasing it as a competing product. given it hasn't cost you any developer wages, you should make a fortune undercutting your employer... its even file-format compatable with theirs ;)
Agreed - much of the layout on the Vectra series cases should be junked and started over. The Vectra VL tower however is very nicely laid out indeed - makes swapping components in and out a breeze - but is so designed around the custom motherboard that replacing the motherboard can be a nightmare.
Some do. The Vectras are basically the same motherboard and other internal components (you lose the remote management stuff, but most companies don't bother with that anyhow, having bought a solution from Microsoft or Novell) If a pavilion is noticiably cheaper, then it makes sense to go for it - particularly if you are buying two or three hundred at a time.
If that is the case, then you really only need to change the format slightly to include timestamped (or sequentially numbered), signed messages rather than unauthenticated ones (timestamps to prevent simple retransmission of commands as a "cut and paste" control system). There are plenty of PK signature solutions out there - but I assume uploading a new program may be a problem - debugging would be a nightmare ;)
I dunno if I'd ever advise anyone to allow their keys to be stored on the server, no matter how many reassurances they get. However, for someone who simply wishes to share private mail with someone else, it might be nice.
not entirely a bad thing - the security of the PGP secret keyring does not require secrecy of the file - if you really want it, I will mail you a copy - but *does* require that the key be encrypted and that a good, unguessable passphrase be used.
at least at first glance, it looks good - actual encryption model is very pgplike, with public keys protecting session keys protecting messages via symmetric encryption; however, even Hushmail has realised that OpenPGP compatability is the way to go, and has set up a site to allow PGP users to import their DH public keys to Hushmail (for use by hushmail users) and export their hushmail keys for upload to keyservers.
With the inclusion of file storage into the pot, it looks like an attempt to take the Hushmail business model and run with it - but unless they move towards OpenPGP compatiability, they will almost certainly lose the interoperability war, and with it a lot of potential users.
the built in keyboard takes quite a bit of getting used to, but you can get up to quite a respectiable typing speed with it, holding the device in both hands and "thumb typing".
Thanks for that - I have just got a DC second hand, and was looking for info on programming it. :)
now have two keyboard/mouse adaptors and a serial cable ordered and on their way, and the rereqs for the linux CD are downloading now
As far as I can tell, yes - even the program itself (scramdisk) can't tell if a scramdisk file really is a scramdisk file unless it tries to decrypt it with the right password.
I am not aware of any reasonable way to statistically distinguish (for example) a 3DES encrypted block from random noise (and a quick websearch didn't enlighten me any further) - Steganographic packages *can* be statistically detected, for two reasons:
First, many don't use crypto at all, and/or have predictable header structures
Second, most use Jpg files for storage, which (due to the lossy compression) then differ from how the image would normally have been compressed (the line transitions are not as smooth as they should be). I don't exactly follow how you detect that programatically, but it is often visible when you compare a before and after.
yes, completely. Hold on, I will read back a bit and try and figure how why we are both arguing the same points :)
*mumble mumble*
Hmm. the original statement I was disagreeing with was that use of unbackdoored crypto would be "easily spotted". I was making the point that it would be hard to spot even non-steganographic crypto unless you deliberately decrypted and exhaustively examined every email sent by anyone (which would be both a massive invasion of privacy, and technically impossible with today's tech)
ah - you *do* realise that Scramdisk steganographic data is encrypted, and therefore is statistically random, yes?
There is also no unencrypted static header data in a scramdisk - purposely to make it impossible to prove a given random stream is a SD and not a keypad for OTP.
I tried this a couple of years back - the lower four bits of a noisy sound sample seem pretty random, to the point where I actually use the lower bits of a sound sample from a noisy source (samples of a radio reciever via a soundcard) as a medium-grade entropy source. I did quite a few conversions, self-pattern matching exercises and FFTs and couldn't find any patterns worth a damn. feel free to try it yourself - as I say, I am actually using this method to generate entropy for crypto, so if it is insecure I would appreciate knowing about it..
Normally, such laws are proposed as "we will retain the right to read your email, but don't worry, we won't actually do so unless you are under investigation"
This works fine if everyone is forced to use the indicated (legal) protection and no better, but in practice, someone can wrapper the illegal stuff with the legal, and nobody will know unless that message (and therefore every message) is checked.
as an analogy - imagine that the USG wanted it to be illegal for the trunk (is that the american term?) of a car to be opaque as leas needed to be able to see what you were carrying in there, so they order that every car must have a little window on the top of the lid of the trunk so that LEA officers can look in if they need to.
however, you could always put an opaque box IN the trunk, and they wouldn't know unless they looked, so the only solution is to have cameras above the roads looking down into EVERY trunk so that they can check for opaque boxes, and just incidentally had better look inside the passenger compartment too, just in case you tried to sneek an opaque box past them there...
Yup, there are probably thousands of cases where they can't go ahead and prosecute because there is no evidence beyond the intercept data, and that data is "tainted" by having been gathered illegally.
Not a good reason to retroactively authorise it though.
Obvious answer to this one - download a (free) copy and try it.
for four bit, I can't hear it at all when playback is via computer speakers or headphones (obviously, not the superior quality hi-fi headphones a music lover would own, but then the soundcard is only a 64 bit soundblaster anyhow) even in very quiet sections of the music.
with the secondary 8 bit method, I *can* hear a noticable hiss, but no more than you would get from a poor quality recording from the radio.
as I said, the key is to not use a "prefect" digital sample to begin with - certainly, for samples recorded via a sound card I have heard worse than the output of the 8 bit mode......
no, because unless you perform 100% monitoring (decrypt every message and look inside it) you don't know if the "authorized" backdoored encryption packet is only an outer wrapper around a PGP message.
The same goes for messages *not* apparently using encryption of course - because if they are ascii armoured pgp, file attachments, zipfiles (possibly password protected), executables or any other of a hundred different things, they *might* have crypto inside them.
The argument of key security is another of course (the big flaw in key escrow is how valuable the escrow database would be; a single corporate key from that database could literally be beyond price, and there would be thousands of them in there)