Making the penalties huge makes it all the more tempting to send spam in your competitor's (or, as the case may be, personal enemy's) name without the trailers -- and also makes it all the more tempting to just operate offshore and forget the whole thing.
Nope. In high-budget mission-critical embedded environments (which are what we're talking about here), the programs getting run will themselves have been proven and desk-checked by multiple teams. Thus, so long as the syscalls do what they're proven to do, and the proofs of the software correctly and accurately reflect the proofs of the syscalls, you've got a complete system which will do exactly what it's proven to do (so long as it remains in an environment in which the proofs are valid, of course).
This is NASA-type stuff; it's an entirely different environment (with different requirements) from almost all other commercial development, and is vastly more expensive to do -- but it makes sense for cases where large numbers of lives or billions of dollars of property ride on the correct operation of your sofware.
No, this particular point is valid -- not specifically applied to Linux, but in general.
Proving algorithms has been part of *real* computer science for decades, and is part of what separates the actual "computer science" folks from the programmers (and the real computer science universities from those which are actually just glorified trade schools).
I'm saying this as a programmer; I don't prove my algorithms personally, but I respect those that do.
Umm, no. "GSM picocell" is not in and of itself the answer -- it's a (generally accepted within the relevant community) term describing what the questioner wished to create (a very small cell); in short, a restatement of the question.
A specific product used to create such a picocell (which Google finds) is the answer.
By the same token when it actually needs to be defended, should it be neccesary to take it to court surely the funds could be raised then.
That covers defense, but not administration -- which, if done properly beforehand, may make the defense much more likely to actually be successful (and inexpensive).
Marked, yes. Clearly, no. I'm simply a casual reader in this context -- I don't notice things which aren't in the way of my eyeball, and the way Yahoo! formats their notice of those results as sponsored, said notice isn't.
Obviously, that Yahoo! is sufficiently interested in advertising income as to compromise the quality of their results by returning sponsored links which aren't clearly and obviously marked as such whereas Google (while still seeking such income) has the decency to avoid permitting their ads to disrupt the user's attempt to read for non-sponsored results.
Yahoo! puts the interest of their advertisers above the interest of their users. Google serves their users first -- and, by doing so, attracts the eyeballs with which to gather advertisors even without using dirty tricks to get their ads viewed.
I wouldn't say the right number is obvious at all -- 50F is livable even for us fragile humans. (Not that the Martian atmosphere, such as it is, would be accomodating without a lot more work).
If the threat model is someone running spyware on the computer-lab machine you use or trying to run some remote exploit on a multiuser system to grab your private key, having said key never touch that machine does you a great deal of good, even if the hardware that does host your private key could be cracked by someone with a bus analyzer and a few minutes of time.
Heh -- so the Linux-USB Gadget folks *do* have an Ethernet-over-USB driver already available and working... yall's hardware does work with the Gadget interface, right?
Is anyone actually developing a USB gadget network-interface module such that this thing can look like an Ethernet device?
I would find it *exceedingly* useful to build a plug-in system which could run a VPN (say, OpenVPN either in tap mode or tun+masquerading for connections from the host), or proxy certain HTTP connections through SSL with a client key, or such -- but while I've done a bit of kernel code now and again, I just don't anticipate having the time in my schedule to do something along those lines *now*.
Nuh-uh, you're parsing that line wrong. Claiming that something shows that hydrogen is an attractive fuel source does not imply that that thing uses hydrogen as a fuel source -- the item in question may simply demonstrate properties of hydrogen (such as burning clean) which arguably make it attractive.
(As for the warts -- well, we'd damn well better have positive-net-return fusion in a few years).
Reread the summary, still don't see it -- and I got outstanding scores for reading comprehension back when I was in school.
Sure, they have some BS about this showing that hydrogen is an attractive fuel, but that's a completely different claim -- the implied argument is that it shows off some of hydrogen's properties (burning clean) which may be likewise applicable when it's used as a fuel.
The F'ing Article certainly doesn't say so. I don't see any comments saying it is. In fact, the only discussion I see about whether this is or isn't a fuel source is... your comment right here.
Who do you think pays our paychecks? We plays along, or we gets replaced. And building a good protection mechanism is enough of a technical challenge to qualify as interesting work. (Yes, I've built one -- intended to make servers housing medical data tamper-resistant, even against the folks who paid for them).
You may not make it easy for them -- but someone will take that paycheck, and be fighting for that pay raise (or just to be noticed above the crowd), and they will.
You could easly descise the game images as pictures just by adding a PNG/JPEG header or whatever the PSP norm is.
Unless one looks for valid images, as opposed to merely valid headers. And again, I'm talking about heuristics -- if you see a ton of images (or a small number of extremely huge images), but almost no code segments, it's time to get suspicious.
Also what stops the pirates distributing the unvalidated code, along with some sort of randomizer that can mix it up a bit. Then individuals can submit this to the automated system and get it verified for thier PSP.
That's not so bad a risk to take at all. The automated system is free, sure, but I never promised that it would be available without registration -- and it knows the serial number of your PSP. Get caught cheating the system (by submitting some code which, either before or after the fact, is found to be intended to hide pirated content)? Not only will you never again be able to get homebrew apps signed for your PSP, but Sony (presuming they keep an archive of who's submitting what) has the ability to come back and sue your asses, or hand evidence over to the game company to let them do so.
And of course, Sony has the ability to extend their heuristics engine to account for whatever tricks are tried against it. Randomly sampling the submitted automated requests for manual review will ensure that there's a level of risk in submitting anything that isn't legit -- not only will they block the request, but they'll be able to extend the heuristics engine to catch and block similar attempts.
Not to mention that if they're keeping good records they'll be able to figure out which PSP (at least by serial number) was first used to develop the trick in the first place. They may then be able to track it as far as location and (at least approximate) date of sale -- which, in addition to whatever info they collected via their submission interface (source address, etc) can give them a pretty good head start on a lawsuit.
Or maybe you've mainly worked for large companies which are big enough to employ someone to setup and maintain that kind of set up.
I am the guy who sets up and maintains remote access. I'm IT, desktop support, an app developer, a revision control specialist, a system-level programmer, an Asterisk consultant, a DBA (in a severe enough pinch)... and so forth. So even when I'm working for somewhere nontechnical -- say a local car dealership [actual past job] and I'm the sole IT guy on staff, I can rig up a VPN when I'm not porting or extending the custom software they run their business off of or fixing the database it backends into or setting up a phone queue or a backup system or helping the secretary do a mail merge or whatever else they happen to need.
Getting a VPN up is not something that takes a dedicated employee -- one sufficiently skilled part-time IT generalist is enough, and that person can typically fill enough gaps to make their employment worthwhile.
Well, that's the entire reason for having the manual step before generating something that can play on multiple PSPs.
That said, if I were writing a is-this-valid-code? heuristics engine, I'd be pretty darned suspicious if the binary didn't make sense (ie. didn't have valid opcodes where expected, had jumps that made no sense, etc etc).
Slashdot Mirror
Making the penalties huge makes it all the more tempting to send spam in your competitor's (or, as the case may be, personal enemy's) name without the trailers -- and also makes it all the more tempting to just operate offshore and forget the whole thing.
Err, no offest, but someone had to do one.
I got a kick out of it. Shame the moderators haven't a similar sense of humor.
I had in mind a system running a single userlevel application, where that application itself is as critical as the kernel.
Send spam in a competitors' name without the legally required trailer. Watch said competitor get hit with lawsuits.
Send spam in your own name. Blatently lie about where you got the addresses. Someone objects? Their word against yours.
Send spam from offshore. Don't bother with the legally required trailer. How's it going to get enforced?
Why do you believe that present activities don't "look legit"?
Can you answer based on the activities themselves, as opposed to the response to them (which arguably itself is the snafu)?
Nope. In high-budget mission-critical embedded environments (which are what we're talking about here), the programs getting run will themselves have been proven and desk-checked by multiple teams. Thus, so long as the syscalls do what they're proven to do, and the proofs of the software correctly and accurately reflect the proofs of the syscalls, you've got a complete system which will do exactly what it's proven to do (so long as it remains in an environment in which the proofs are valid, of course).
This is NASA-type stuff; it's an entirely different environment (with different requirements) from almost all other commercial development, and is vastly more expensive to do -- but it makes sense for cases where large numbers of lives or billions of dollars of property ride on the correct operation of your sofware.
No, this particular point is valid -- not specifically applied to Linux, but in general.
Proving algorithms has been part of *real* computer science for decades, and is part of what separates the actual "computer science" folks from the programmers (and the real computer science universities from those which are actually just glorified trade schools).
I'm saying this as a programmer; I don't prove my algorithms personally, but I respect those that do.
Umm, no. "GSM picocell" is not in and of itself the answer -- it's a (generally accepted within the relevant community) term describing what the questioner wished to create (a very small cell); in short, a restatement of the question.
A specific product used to create such a picocell (which Google finds) is the answer.
Marked, yes. Clearly, no. I'm simply a casual reader in this context -- I don't notice things which aren't in the way of my eyeball, and the way Yahoo! formats their notice of those results as sponsored, said notice isn't.
Yahoo! puts the interest of their advertisers above the interest of their users. Google serves their users first -- and, by doing so, attracts the eyeballs with which to gather advertisors even without using dirty tricks to get their ads viewed.
Perhaps you didn't notice that the EBay "failure" link returned by Yahoo! isn't clearly marked as sponsored, whereas Google's comparable return is?
I wouldn't say the right number is obvious at all -- 50F is livable even for us fragile humans. (Not that the Martian atmosphere, such as it is, would be accomodating without a lot more work).
Now, 50K, yes, *that's* chilly.
Depends on your requirements.
If the threat model is someone running spyware on the computer-lab machine you use or trying to run some remote exploit on a multiuser system to grab your private key, having said key never touch that machine does you a great deal of good, even if the hardware that does host your private key could be cracked by someone with a bus analyzer and a few minutes of time.
Heh -- so the Linux-USB Gadget folks *do* have an Ethernet-over-USB driver already available and working... yall's hardware does work with the Gadget interface, right?
Is anyone actually developing a USB gadget network-interface module such that this thing can look like an Ethernet device?
I would find it *exceedingly* useful to build a plug-in system which could run a VPN (say, OpenVPN either in tap mode or tun+masquerading for connections from the host), or proxy certain HTTP connections through SSL with a client key, or such -- but while I've done a bit of kernel code now and again, I just don't anticipate having the time in my schedule to do something along those lines *now*.
Remember, they're running a cluster made of hordes of cheap, little machines -- vastly more machines than they have employees.
Also remember that they didn't always have that market cap, or any.
It's right there, the last line of the /. blurb:
Nuh-uh, you're parsing that line wrong. Claiming that something shows that hydrogen is an attractive fuel source does not imply that that thing uses hydrogen as a fuel source -- the item in question may simply demonstrate properties of hydrogen (such as burning clean) which arguably make it attractive.
(As for the warts -- well, we'd damn well better have positive-net-return fusion in a few years).
Reread the summary, still don't see it -- and I got outstanding scores for reading comprehension back when I was in school.
Sure, they have some BS about this showing that hydrogen is an attractive fuel, but that's a completely different claim -- the implied argument is that it shows off some of hydrogen's properties (burning clean) which may be likewise applicable when it's used as a fuel.
The F'ing Article certainly doesn't say so. I don't see any comments saying it is. In fact, the only discussion I see about whether this is or isn't a fuel source is... your comment right here.
Realism, please.
Who do you think pays our paychecks? We plays along, or we gets replaced. And building a good protection mechanism is enough of a technical challenge to qualify as interesting work. (Yes, I've built one -- intended to make servers housing medical data tamper-resistant, even against the folks who paid for them).
You may not make it easy for them -- but someone will take that paycheck, and be fighting for that pay raise (or just to be noticed above the crowd), and they will.
You could easly descise the game images as pictures just by adding a PNG/JPEG header or whatever the PSP norm is.
Unless one looks for valid images, as opposed to merely valid headers. And again, I'm talking about heuristics -- if you see a ton of images (or a small number of extremely huge images), but almost no code segments, it's time to get suspicious.
Also what stops the pirates distributing the unvalidated code, along with some sort of randomizer that can mix it up a bit. Then individuals can submit this to the automated system and get it verified for thier PSP.
That's not so bad a risk to take at all. The automated system is free, sure, but I never promised that it would be available without registration -- and it knows the serial number of your PSP. Get caught cheating the system (by submitting some code which, either before or after the fact, is found to be intended to hide pirated content)? Not only will you never again be able to get homebrew apps signed for your PSP, but Sony (presuming they keep an archive of who's submitting what) has the ability to come back and sue your asses, or hand evidence over to the game company to let them do so.
And of course, Sony has the ability to extend their heuristics engine to account for whatever tricks are tried against it. Randomly sampling the submitted automated requests for manual review will ensure that there's a level of risk in submitting anything that isn't legit -- not only will they block the request, but they'll be able to extend the heuristics engine to catch and block similar attempts.
Not to mention that if they're keeping good records they'll be able to figure out which PSP (at least by serial number) was first used to develop the trick in the first place. They may then be able to track it as far as location and (at least approximate) date of sale -- which, in addition to whatever info they collected via their submission interface (source address, etc) can give them a pretty good head start on a lawsuit.
Getting a VPN up is not something that takes a dedicated employee -- one sufficiently skilled part-time IT generalist is enough, and that person can typically fill enough gaps to make their employment worthwhile.
Well, that's the entire reason for having the manual step before generating something that can play on multiple PSPs.
That said, if I were writing a is-this-valid-code? heuristics engine, I'd be pretty darned suspicious if the binary didn't make sense (ie. didn't have valid opcodes where expected, had jumps that made no sense, etc etc).