Re:Your home is private. Internet boradcasts are n
on
Echelon in the News
·
· Score: 1
If I send a mail to person X, that is not a broadcast. It is what should be a private communication.
Now, I agree that there is little or no legal basis for me assuming that privacy will be protected, but that can (and must) be solved by changing the laws. It's not because the lawmakers of 100 or more years ago did not envisage internet when considering whether regular mail should be private, that the founding moral principles behind the laws that they made do not apply to that same internet.
Or maybe: "Honey, the doctor said my abdominal swelling was caused by a sperm virus. Apparantly it's quite easy to pick this thing up. He said it could even have happened by accident in his cabinet, given the number of ill people that pass through there."
The key thing you need to remember is that clever does not equal fit. It all depends on the environment who or what is the fittest.
If we (repeatedly) stuff an average university maths student, an Arnold Schwarzenegger type, and a hungry lion in a pit without any tools and wait for their to be only one survivor, the fittest will come out, even if on average it ain't the student. If we repeat the experiment adding a mathematical puzzle that gives right to escape when solved, the fittest will survive even if it is sometimes is one of those stereotype fat geeks of maths with unbelievably strong glasses and no sense of normal social behaviour.
With all due respect for one of the true giants of the semiconductor and IT industries, but I don't think he has to be the best man to ask about the future. Not because he says so himself (for those who didn't read the article: he does), but because he's been involved in it for so long already.
In general, the fate of all experts (especially in a world moving as fast as ours does nowadays) is that, with aging, they inevitably get to a point where they don't see the changes coming anymore. They end up relying more and more on extrapolations of their own (sometimes vast, but still very limited) knowledge and experience. At some point these extrapolations break down completely. IMHO, it's a rare person who understands this to be applicable to himself or herself in time. Those who do, stop making predictions years into the future anyway.
Not so long ago, it was mentioned here on/. that some spammer victim lists are edited to remove the most vocal anti-spam people, so as not to attract their attention. That basically means that by being a pain in the ass these guys have won as far as their own inbox is concerned.
Now, someone who justs collects the cookies and otherwise doesn't do anything is not a pain in the ass. My cookie filtering works in a different way, though. I accept ad related cookies at first, but then remove them later on by means of a cron script. This means that each time they give me one, they think they've got a new customer to track. I don't plan on changing that, since it's an essential part of being a pain in their ass. What would be new if the ads become too anoying, is that in addition I'd be pestering not the ad companies, but their clients.
Hello Mr. troll,
your ideal world is dream, a flight of imagination, and cannot be had. Privacy can. Not always, but often enough to be worth preserving.
It would be simple enough to tie advertising to a time-span of site viewing using a cookie. You view one complete ad and your good for the day.
I'm sorry but I will never allow ad related cookies on my accounts. They all straight go into the bitbucket today, and will do so in the future as well.
If I find that I need one of those browsing habit trackers just to suppress the damn ads on site X, site X has seen the last of me. Well, almost: I'd send them a polite but firm (template) mail explaining the problem in detail and then never return.
I haven't seen it, but one potential answer to you question seems simple enough.
Suppose for a start that you have an infected file. Irespective of wether this is a PE or an ELF file, it is should be obvious that this can be capable of infecting both PE and ELF files. It doesn't have to be PE/ELF to understand PE/ELF and produce a valid PE/ELF. So, once you have one infected file, it can spread across OS-es, provided that it can get hold of files to infect. The latter is easy: many people will install just about anything, and still use floppies or Zip/Jazz like drives to share stuff with friends, etc. Bootstrapping is just as easy: just start out with two versions of the virus, one in each format.
The only minor problem is distribution via attachment, since whatever version you send out, it will only work on a subset of the machines that it reaches. But this is nothing new: it's true for all attachment based nasties and hasn't stopped any of them. Besides, it's easy to solve: just send out both of versions.
Not really. I know several people of the "technical manager" variety who can (and do) use a dual boot portable both ways, but who are not at all capable of setting it up or understanding all the consequences.
We have a number of dual boot portables with NT for the pointyhears to use for whatever they do "normally" and Linux for them to use when demonstrating our products. These machines are originally installed by our computer support group (and thus have virus scanners and all that), but how are these guys supposed to update the virus scanner in time if a machine is collecting more frequent flyer miles in one year than an average employee in a lifetime?
--
Nope, it's a good thing
on
NSA Inside?
·
· Score: 1
The most likely story is that this tool is something the NSA would like to use, but is not brought to
the level of functionality to make it truly secure from the NSA itself.
So? If they give us something which only they can crack, we're still a lot better of than without it. They can get in anyway. As can many others who would not be able to bypass the NSA stuff.
As long as you get to see and change the source, so there really is no need to fear the things they give you. At most it's the ones they do not give you that should worry the paranoiacs out here.
I can't believe it! Skipping the most important word. Where was my mind??? Anyway, here's what I actually wanted to say:
The morons you mention decided this because otherwise EU meat could not be exported to several
non-EU countries (including the US). Morons indeed. Everywhere.
The morons you mention decided this because otherwise EU meat could be exported to several
non-EU countries (including the US). Morons indeed. Everywhere.
Actually, what a billion is depends on where you are and what language you speak. Some or all of those who call 1000 million a milliard, will say that a billion really is a million million.
In dutch, for instance:
1 million = 1000 thousand
1 milliard = 1000 million
1 billion = 1000 milliard
1 billiard = 1000 billion
1 trillion = 1000 billiard
When I buy a book I pay because, after due consideration and flipping the pages x times in the bookshop, I consider that the author has put in sufficient
effort and knowledge for me to gain something
from the buying/reading whole thing. Or at least, with a big enough probability.
With/., this is very different. Most of the content is not worth paying for, and there is no "just flpipping the pages for evaluation purposes" concept. Therefore, if I have to pay to even find out whether something interesting is hiding between the drivel, I'm gone.
But there is more./. is a discussion site, largely created by its users, so even charging people to write is not a good idea. I personally don't post often, but when I do, I want to be able to do it before the whole discussion is yesterday's news. At such moments, I'm not interested in first sorting out what to pay and how. In addition, I most often post when I want to contribute something I already know, not when I want to get something back. In other words, posting from home already costs me (time and money, because here in Europe there is no such thing as free local telephone connections).
So I'd have to pay (even more) up front, for a service that I rarely use and often don't personally benefit from. So I wouldn't. As I know quite a few other people who would come to the same conclusion, the end result would be a lot less posts and readers.
Just for completeness: there is no way that I could convince my employer to pay a subscription for me. They probably think it's bad enough already that they have to pay me (and our provider) while I'm wasting some of their time and bandwidth over here. Yet another reason why I'd have to leave in case/. were to start charging just for reading/writing stuff.
Indeed,/tmp would be an option (not/var/tmp, as it often is too small already). Except that on multiuser servers you want to run cron scripts to clean up the mess people create there. I'm not sure how tolerant browsers are w.r.t. single cache files being removed while they're still running. Some of us actually never log out and (amazingly) even keep NS running for weeks on end.
PS: Sorry for all the typos in my previous post.
I was facing a very hard deadline when typing that one and skipped the preview.
For the sake of correctness: IE 5 runs on Solaris and HP-UX. In fact, on request of our sysadmins I'm in the process of evaluating it as a potential replacement for NS4 on out HP-UX boxen (not that I personally will ever end up using it, but they want my opinion, so...).
NS6 is considered unusable over here. Mozilla stands no chance whatsoever to become a supported tool here due to PHB fears about a lack of support. Sad, but true.
Using de filesystem cache as memory cache is nice if you use local disks. In an typical UNIX enterprise environment, home directories are not local but NFS mounted from some fileserver, which introduces serious latency. In addition, these environments typically use a proxy server as well, which already has a disk cache.
Both of these combined mean
that an somebody using disk cache for NS 4 is a no-op in terms of speed and a waste in terms of disk space. In fact, the computer group overhere expicitly tells everyone on UNIX not to use disk cache. The, if no disk cache also means no memory cache...
Maybe I'm overworked (don't feel like it, though), but I've personally run into this NFS limit. The thing is that not all projects worth keeping around are actively being worked on (and definitely not by everybody who may need read access). There is also the stuff that is stiil being used and maintained at low priority, but no longer being developed. Not all groups belong to projects either. Consider software installations (of stuff too complex to just throw onto the large pile of crap usually called/usr/local). Then there also are things such as the "monthly computer group vs computer users" workgroup meetings. I'm involved in one of those at work. They take me 1 to 2 hours a month, but would require a group anyway.
Regarding the access vs. content stuff: What about having multiple versions of the same document? E.g. a complete one for the developers, and an executive overview for the users, and an executive executive overview with possibly some extra confidential long term strategic annotations for the PHBs? Those belong together (hell, they might even be derived from the same LaTeX source), yet security is very different. And next thing you know is that security requirements change (I've had this happen several times: stuff that starts out as "developers only" gradually gets propagated upwards and outwards.)
Others have already mentioned that the above proposal suffers from combinatorial explosion.
Hence, I will limit myself to these:
Organizing your data hierarchically by who
has access to it is bad. Data should
be organised based mainly on its (hopefully somewhat constant)
logical structure, not by something as
volatile as who is allowed to see it at any given moment in time.
NFS (at least up to version 3) does not
support more than 1 primary + 15 other
groups per user.
Basically, the subject says it all. But just in case: I'm free to use Linux at home (I do), but I'm not free to use it at work (yet). We have some Linux machines, but only a few, and IT doesn't like them. The problem is that, even though I have a big say in what we use, I don't have the final one. The PHBs of many IT departments still are M$ fanatics, even if they don't know anything at all about computers. Ours is no exception. Hence, the more commercial backing Linux gets, the easier it becomes for me to obtain the freedom to use Linux at work. QED
There is no connection between coding their bond pricing engine into kernel space and their rivals being able download that technology from RedHat.com. In order for the latter to be possible, the code would have to be uploaded to RedHat.com first, and this is something the originating bank has control over. (I'm making abstraction of security breaches now, because those apply just as well if they use all closed source products to run their stuff on.)
It is not the case that all changes to a custom Linux kernel must be made public.
I like the analogy with natural evolution that previous poster made. There's a lot of truth in that. On the other hand, one big difference is that nature does not know where it is supposed to end up, while a decent programmer does know (OK, not all of the time, but often enough). The latter is one of the things invalidates the "Yeah, and look where it got us." counter argument. The other is that there is no reason why pushing a person with half his weight and him having to counteract would be inherently bad. It all depends on what the specs call for and whether a better design compromise that satisfies them is actually feasible.
Indeed, often when I'm doing the incremental rework. I know very well where I want to end up in the end. It's just that ending up there after restarting from scratch is not always feasible within the constraints imposed by real life. What follows may be new to some of us out here, but software that is actually worth a rewrite tends to have active users who want bug fixes and new features now, not 2 years down the line. Maintaining the current version may also be what keeps the money coming in that is supposed to pay for all the rewriting.
I agree that clean code instantiating a good architecture is the max. But almost clean code instantiating an architecture that is actively on its way to become good is still a lot better than one pile of obfuscated dung that only pretends to work, and a pile of paperwork documenting a new and shiny system that didn't get more than half implemented before real life intervened. Of course, some systems are way beyond rescue. When I run into one of those, I too call for a rewrite and otherwise refuse to work on them.
That depends on how you go about it (and how bad the original design is, obviously). The key issue is not to get bogged down in rewriting functions (or worse: just parts of them), but to also (gradually) rewrite the design. Does the term refactoring ring a bell? If not, look up Martin Fowler's book.
Anyway, if you're good enough a programmer to recognise the badness of the old design and come up with something better, the risk of ending up with nice and shiny code trapped in a bad old design isn't all that large, IMHO. If you're not good enough, you're doomed anyway. Even if you restart from scratch.
Also, if you have a working program to start from, or at least one that does at least some things right, gradual changes can be quite easy to apply and debug, even if they're design changes. This has the nice effect of providing a stream of small but nice successes that both keep you going and can help to convince management that it's worth investing some more and that you are capable of dealing with that. You do have to be willing to compromise and eat the cake in somewhat smallish bites, though. Don't shoot for the big ultimate design from the start. Instead, go for something that is 1) better than what you've got; 2) reachable; and 3) a suitable starting position to move closer to your ultimate goal at some later stage. Extra advantage: if, for whatever reason, you have to abandon the rewrite before it's done, your legacy is much more likely to still be usable.
One somewhat nasty but potentially also very big advantage is that the gradual approach can help to get the work done even if management is all PHB and doesn't recognise (let alone have) a 10 foot clue if it hits them in the face. Basically, you don't have to tell them all the gory details of what you're doing (which is not the same as lying about it). Of course, not all company cultures will allow for this.
I've done all this several times, both at work and in my spare time. So far it always worked.
You wanted to be corrected in case you were wrong, so here goes: On this page about why the GPL is good, RMS specificly gives the example of someone wanting to use (i.e. interface with) readline (which is under GPL) and not being allowed to do so until he put his own work under the GPL too.
I understand the desire to go open source here, but please be careful about what it means. Not all that much actually.
I would definitely not trust a voting booth more because the source code was put under GPL. Why? Because there is no guarantee whatsoever that the stuff that is actually running things really was compiled from exactly the source that I (or someone I trust) saw/reviewed. Neither is there any guarantee that the actual compiler used for compiling it was "clean" and did not introduce any backdoors (even if that too is open source). For reference, consider Dennis Ritchie's famous compiler hack
On the contrary, if the source is open, just about any programer can build a modified version and set up a trojan voting booth. Millions of computer illerate people would never even think of this being possible, let alone be careful about where and how they cast their vote.
Slashdot Mirror
Now, I agree that there is little or no legal basis for me assuming that privacy will be protected, but that can (and must) be solved by changing the laws. It's not because the lawmakers of 100 or more years ago did not envisage internet when considering whether regular mail should be private, that the founding moral principles behind the laws that they made do not apply to that same internet.
--
--
The key thing you need to remember is that clever does not equal fit. It all depends on the environment who or what is the fittest.
If we (repeatedly) stuff an average university maths student, an Arnold Schwarzenegger type, and a hungry lion in a pit without any tools and wait for their to be only one survivor, the fittest will come out, even if on average it ain't the student. If we repeat the experiment adding a mathematical puzzle that gives right to escape when solved, the fittest will survive even if it is sometimes is one of those stereotype fat geeks of maths with unbelievably strong glasses and no sense of normal social behaviour.
--
With all due respect for one of the true giants of the semiconductor and IT industries, but I don't think he has to be the best man to ask about the future. Not because he says so himself (for those who didn't read the article: he does), but because he's been involved in it for so long already.
In general, the fate of all experts (especially in a world moving as fast as ours does nowadays) is that, with aging, they inevitably get to a point where they don't see the changes coming anymore. They end up relying more and more on extrapolations of their own (sometimes vast, but still very limited) knowledge and experience. At some point these extrapolations break down completely. IMHO, it's a rare person who understands this to be applicable to himself or herself in time. Those who do, stop making predictions years into the future anyway.
--
Now, someone who justs collects the cookies and otherwise doesn't do anything is not a pain in the ass. My cookie filtering works in a different way, though. I accept ad related cookies at first, but then remove them later on by means of a cron script. This means that each time they give me one, they think they've got a new customer to track. I don't plan on changing that, since it's an essential part of being a pain in their ass. What would be new if the ads become too anoying, is that in addition I'd be pestering not the ad companies, but their clients.
--
your ideal world is dream, a flight of imagination, and cannot be had. Privacy can. Not always, but often enough to be worth preserving.
--
I'm sorry but I will never allow ad related cookies on my accounts. They all straight go into the bitbucket today, and will do so in the future as well.
If I find that I need one of those browsing habit trackers just to suppress the damn ads on site X, site X has seen the last of me. Well, almost: I'd send them a polite but firm (template) mail explaining the problem in detail and then never return.
--
Suppose for a start that you have an infected file. Irespective of wether this is a PE or an ELF file, it is should be obvious that this can be capable of infecting both PE and ELF files. It doesn't have to be PE/ELF to understand PE/ELF and produce a valid PE/ELF. So, once you have one infected file, it can spread across OS-es, provided that it can get hold of files to infect. The latter is easy: many people will install just about anything, and still use floppies or Zip/Jazz like drives to share stuff with friends, etc. Bootstrapping is just as easy: just start out with two versions of the virus, one in each format.
The only minor problem is distribution via attachment, since whatever version you send out, it will only work on a subset of the machines that it reaches. But this is nothing new: it's true for all attachment based nasties and hasn't stopped any of them. Besides, it's easy to solve: just send out both of versions.
--
We have a number of dual boot portables with NT for the pointyhears to use for whatever they do "normally" and Linux for them to use when demonstrating our products. These machines are originally installed by our computer support group (and thus have virus scanners and all that), but how are these guys supposed to update the virus scanner in time if a machine is collecting more frequent flyer miles in one year than an average employee in a lifetime?
--
So? If they give us something which only they can crack, we're still a lot better of than without it. They can get in anyway. As can many others who would not be able to bypass the NSA stuff.
As long as you get to see and change the source, so there really is no need to fear the things they give you. At most it's the ones they do not give you that should worry the paranoiacs out here.
--
The morons you mention decided this because otherwise EU meat could not be exported to several non-EU countries (including the US). Morons indeed. Everywhere.
--
--
In dutch, for instance:
1 million = 1000 thousand
1 milliard = 1000 million
1 billion = 1000 milliard
1 billiard = 1000 billion
1 trillion = 1000 billiard
etc.
--
But there is more. /. is a discussion site, largely created by its users, so even charging people to write is not a good idea. I personally don't post often, but when I do, I want to be able to do it before the whole discussion is yesterday's news. At such moments, I'm not interested in first sorting out what to pay and how. In addition, I most often post when I want to contribute something I already know, not when I want to get something back. In other words, posting from home already costs me (time and money, because here in Europe there is no such thing as free local telephone connections).
So I'd have to pay (even more) up front, for a service that I rarely use and often don't personally benefit from. So I wouldn't. As I know quite a few other people who would come to the same conclusion, the end result would be a lot less posts and readers.
Just for completeness: there is no way that I could convince my employer to pay a subscription for me. They probably think it's bad enough already that they have to pay me (and our provider) while I'm wasting some of their time and bandwidth over here. Yet another reason why I'd have to leave in case /. were to start charging just for reading/writing stuff.
--
PS: Sorry for all the typos in my previous post. I was facing a very hard deadline when typing that one and skipped the preview.
--
NS6 is considered unusable over here. Mozilla stands no chance whatsoever to become a supported tool here due to PHB fears about a lack of support. Sad, but true.
--
Both of these combined mean that an somebody using disk cache for NS 4 is a no-op in terms of speed and a waste in terms of disk space. In fact, the computer group overhere expicitly tells everyone on UNIX not to use disk cache. The, if no disk cache also means no memory cache...
--
Regarding the access vs. content stuff: What about having multiple versions of the same document? E.g. a complete one for the developers, and an executive overview for the users, and an executive executive overview with possibly some extra confidential long term strategic annotations for the PHBs? Those belong together (hell, they might even be derived from the same LaTeX source), yet security is very different. And next thing you know is that security requirements change (I've had this happen several times: stuff that starts out as "developers only" gradually gets propagated upwards and outwards.)
--
--
--
It is not the case that all changes to a custom Linux kernel must be made public.
--
Indeed, often when I'm doing the incremental rework. I know very well where I want to end up in the end. It's just that ending up there after restarting from scratch is not always feasible within the constraints imposed by real life. What follows may be new to some of us out here, but software that is actually worth a rewrite tends to have active users who want bug fixes and new features now, not 2 years down the line. Maintaining the current version may also be what keeps the money coming in that is supposed to pay for all the rewriting.
I agree that clean code instantiating a good architecture is the max. But almost clean code instantiating an architecture that is actively on its way to become good is still a lot better than one pile of obfuscated dung that only pretends to work, and a pile of paperwork documenting a new and shiny system that didn't get more than half implemented before real life intervened. Of course, some systems are way beyond rescue. When I run into one of those, I too call for a rewrite and otherwise refuse to work on them.
--
Anyway, if you're good enough a programmer to recognise the badness of the old design and come up with something better, the risk of ending up with nice and shiny code trapped in a bad old design isn't all that large, IMHO. If you're not good enough, you're doomed anyway. Even if you restart from scratch.
Also, if you have a working program to start from, or at least one that does at least some things right, gradual changes can be quite easy to apply and debug, even if they're design changes. This has the nice effect of providing a stream of small but nice successes that both keep you going and can help to convince management that it's worth investing some more and that you are capable of dealing with that. You do have to be willing to compromise and eat the cake in somewhat smallish bites, though. Don't shoot for the big ultimate design from the start. Instead, go for something that is 1) better than what you've got; 2) reachable; and 3) a suitable starting position to move closer to your ultimate goal at some later stage. Extra advantage: if, for whatever reason, you have to abandon the rewrite before it's done, your legacy is much more likely to still be usable.
One somewhat nasty but potentially also very big advantage is that the gradual approach can help to get the work done even if management is all PHB and doesn't recognise (let alone have) a 10 foot clue if it hits them in the face. Basically, you don't have to tell them all the gory details of what you're doing (which is not the same as lying about it). Of course, not all company cultures will allow for this.
I've done all this several times, both at work and in my spare time. So far it always worked.
--
--
I would definitely not trust a voting booth more because the source code was put under GPL. Why? Because there is no guarantee whatsoever that the stuff that is actually running things really was compiled from exactly the source that I (or someone I trust) saw/reviewed. Neither is there any guarantee that the actual compiler used for compiling it was "clean" and did not introduce any backdoors (even if that too is open source). For reference, consider Dennis Ritchie's famous compiler hack
On the contrary, if the source is open, just about any programer can build a modified version and set up a trojan voting booth. Millions of computer illerate people would never even think of this being possible, let alone be careful about where and how they cast their vote.
--