Sorry, didn't mean to mock, it's just amusing whenever these one-time pad things come up and everyone starts jumping up and down yelling "unbreakable" and others start going "no, 'cos, like, we could brute-force it.."
You can't brute-force a one-time pad. That's the point. There are many weaknesses to OTP, related to key exchange, but you can't brute force it, because you have no way of knowing if you're right, or even if you're close. The possible set of plaintexts from a properly OTP encrypted message is the complete set of possible plaintexts of that size (or smaller, plausibly).
Let us take the following ciphertext:
aaa
I have encrypted this with a one time pad. Now, it's a pretty short message. We could brute force all the possible combinations on your regular computer pretty much instantly. Anyone care to guess what the message might be?
Of course not, because it could be *any* 3 letter combination, assuming that I'm sticking to letters. Any attempt to contextually analyse it is flawed because you will never be able to prove you got it right. Let's say that we know the message is english, and we can therefore reduce the number of possibilities down to all 3 letter english words.
Woohoo. It doesn't help, it doesn't get us any closer to knowing exactly what it is, because there is no next step, the only information that can aid us in the decryption of a one time pad is information from "outside" the decryption. In this case, two items of information are available to us, the length (3 letters) and the fact that it is english, but the actual ciphertext itself is of no value whatsoever. It doesn't matter if those a's were z's or q's or anything else, we can't do anything with them unless we have the OTP.
"Decrypt candidates with "bad" and "moo" in them would definitely merit further analysis"
This is always the point where things go wrong:) there *is* no further analysis you can make. lets take the following:
abskjhsglkjlssdkglkjsfdlkgjfld
Now lets imagine that we knew it was coming from bank robbers. Sweet, so, what can we do? again, the *only* information we have is the length. It could say this:
I am going to rob a bank in WA
Or this:
I am going to rob a bank in CA
Or this:
I am going to rob a bank in NZ
And there is no way to prove what it actually says at all. It might say:
I am going to buy some flowers
Again, you'll never know unless you have the key, there's just no way to tell.
Intriguing. I guess your situation wasn't that different from mine (http://exorsus.net/), but I started out with very few people as part of the collective (3 of us in fact), and the bills were never very high anyway, so, we're still a collective, kinda. different people have paid the bills at different times, sometimes me only, sometimes me and up to 4 others, right now just me and one other guy, but it has worked out nicely. Never be a business tho.
Brief elaboration: if you apply for a patent, you have to disclose your innovation to the state. But you don't have to apply for a patent, so this isn't seizure as much as it is a trade: you give up ownership of your property later for legal protection by the state today. But copyrights are different. You don't have to apply for copyright protection; every written work gets it automatically. This is the good part. But that copyright protection expires (!!) after a time, at which point the author's property rights are revoked and his property is seized by the state. How would you feel if your house only belonged to you for 20 years, after which time you'd have to give it to the state? Property doesn't work like that in our culture. The idea of "the commons" is almost always invoked to refer to the idea that somehow property isn't really property, and that everything really belongs to the state, or "the commons." It's used to justify seizure of property by invoking a high-minded notion of greater good.
Nono, Copyright is a trade too. In return for the right to sue via the courts for breach of copyright, you have to eventually give it up. This is not seizure, because you don't have to give it up at all, you can not tell anyone and it will be yours forever.
That is the equivalent to a house. You do not own ideas or works, you own your brain and your house and your computer. While your ideas are in there, they are yours. When they are released, by general agreement you recieve the right to determine how they are distributed for 20 years, because it was seen at the time as impetus to release ideas. But you don't own the idea.
Nothing is taken from you that was not given to you in the first place when copyright expires.
> You'll have to explain to me how that's easier than dragging the application out of the DMG file into the Applications folder.
It's much easier. You don't need to know where to get the application, you don't need to go download the DMG file. Everything done for you, just type "apt-get install mozilla" and wait. Local mirrors of everything for added speed.
In addition, it takes care of dependencies (although I acknowledge that the Apple mechanism of "One-file-for-the-app" is a good alternate solution to this a lot of the time), and allows you to go and upgrade any or all installed applications without having to remember where you got it, go and find it, download it again etc etc.
Even further, you can do full searches of available applications using apt-cache, allowing you to quickly and easily locate, for example, and mp3 player or a video encoder immediately available for installation.
APT really is very very good. All kudos to Apple for many of their usability features, but in this one area Debians devotion to Free software has given it leverage which has proven difficult for other operating systems to match, a supply of almost all the software you'll ever need on your system, right here, right now.
Most people here have said something interesting and on the point, but few seem to have put them all together. The point is whether Mozilla is Open or Free. We keep mixing these terms up because in many instances, to us as progammers, they're pretty interchangable.
However in something like this, there's actually a big difference. For something that is Open Source, protecting the trademark makes sense. The project has an identity and there is no reason why that identity shouldn't be protected. This may place restrictions on changes or use of material, but the *code* is still there, still changable, still redistributable.
For something that is Free Software however, its completely different. The objective here is not identity, even with the GNU/Linux calls. The objective is Freedom as in Speech, to do as you wish with the software so long as you grant others the same freedom. It's no good for the original author to have more freedom than other contributors, in the software or in the naming or in anything. The key to quality should not be "what it is", but "who it came from". The "source", from program code to vector graphics files for the logos and buttons to anything else appropriate should be available so that anything the user wishes to change can be changed.
And this is why it's an issue for the Debian group. They're really into Free, they like Free and for Debian, Free is definitely the preferance since they make a number of changes on many projects to help them fit into the distribution as a whole better.
Of course, people will do bad things. Don't ever be under the illusion that Free or Open things always improve. Sometimes, someone does something almost terminally stupid with a project. The point, however, is that nothing is *lost*. The original is still there, and if the reputation concept works, the best will float to the top from collective experience.
So don't get annoyed when Debian screws something up and mozilla gets bug reports. It's going to happen, the only way to prevent it, will prevent the benefits you get as well, and the benefits outweigh the downsides by a staggering degree. Lets not get too fussed and throw the baby out with the bathwater (or the email out with the spam if you prefer). We can deal with this kind of thing in ways other than removing our freedom.
I think its quit clear that there are a suspicously low number of unexplained explosions, leading me to conclude that explanations for many explosions are bogus and therefore that there are many strangelets hitting the earth every year and a concerted effort to cover this up to avoid insurance hikes.
Except that, in the US, no lunatic would ever enter a house with a knife. He'd take a gun, possibly a semi-automatic, because he'd be pretty sure you'd have one. Thus, instead of having a badly injured family who may well survive with medical assistance, you have a family who have been well and truely killed by high-velocity pieces of lead.
Escalation does not apply only to nuclear weapons.
And yes, I fit both of them, plus a 2.4 kernel, on a 1.44mb floppy with no special formatting or anything. Admittedly it was a custom assembly but it was more than worth it for the advantages that these applications offer.
Its gig ether on a (generally) switched network. You can purchase 10, 100 or gig endpoints from citylink. More details are available on www.citylink.co.nz.
Finances and software
on
Slashdot Updates
·
· Score: 3, Insightful
Ironic that here in the middile of tech obsession nobody has thought about trying to get software to solve these financial issues.
The reason the Slashdot guys don't know what they'd charge for a subscription is because they don't know. They can't know. Any value that they choose is going to be based on several factors over which they have no control:
1. The number of people who will actually subscribe
2. The number of people who will leave
3. The number of people who will continue reading slashdot with ads
4. The number of people who will continue reading slashdot with ad blockers
5. Price of bandwidth and hosting
6. Banner ad cpm value
In addition to that, there are factors over which they have limited control:
6. Amount of bandwidth used
Put that all together and in the human world you have what is called a hunch, or a guess, or any other term which indicates that you really have no idea and everything could go to shit inside of 5 minutes.
The natural human solution to this is to look at near-worst-case scenarios and attempt to budget for that happening. The best people at this are in the insurance industry. These are called Damn Good Guesses, but they're still guesses.
The major problem with the future is that the further into the future you look, the less accurate your guess is likely to be. Guessing banner ad prices 20 seconds from now, armed with current prices, isn't a big risk, and you're not likely to be off by much even if you get it wrong. Guessing 2 years from now is near impossible.
So what we need is a way of taking all the unknown variables and guessing rapidly, in short increments, using good solid math principles, in order to determine the value of those variables we do control (cost of subscription, bandwidth to release).
In essence, a floating, self-insuring market run by a well written software agent that would take account of the various costs, the insurance probabilities involved in failed predictions, and how well it can limit the release of bandwidth, and set subscription prices based on that.
Effective tools placed in the hands of users would then let them take advantage of this by limiting the value range within which they are willing to subscribe, and see transparently the decisions being made by the software and the basis for these.
Essentially creating a resubscription process in which users automatically resubscribe every day or maybe even hour or less, and in which the code is open and its behaviour displayed for those who wish to look, it can act in the best interests of both the site, the owners and the users, keeping prices at their lowest practical point while still making a set amount of money for the owners, covering the bandwidth costs and insuring the site against price shocks in the future.
There is the technical expertise around to achieve something like this, and I think Slashdot is a perfect testing ground for this kind of software. The combination of a couple of hot-shot financial guys and a bunch of good programmers could provide software that could keep any number of valuable internet sites afloat in a world so volatile that any number of valuable sites are falling down due to bad guesses on the part of their management.
I would try it, but the only release for linux appears to be 3.02, and they've released v4.0 now, not to mention the next generation Studio product. Whats with that?
The code necessary to resolve this problem is literally a 4 line patch to openssh. I'm not kidding, I did it myself, they even have comments in most of the places you need to put it. I added a -z option which creates randomised network noise, uses from 400 to 1200b/s of packets that look just like password character packets. The support is in the protocol already, it requires no modifications to sshd, and it works fine. The only issue is the additional use of bandwidth.
This, of course, is the problem that everyone is interested in. Its an easy problem to solve, 4 lines, but not an easy problem to solve nicely, in a way that won't result in an increase in the amount of bandwidth used by an ssh application.
I don't believe its really worth worrying about. If you're really paranoid, you should add a patch like mine or run over freeswan or something. In general, its not a script-kiddie vuln.
1. I agree, I would love to give this a go with perl though (pure perl), it would be interesting to see whether it copes as well.
2. Yeah, lots of people seem to have jumpedon the java bandwagon and dumped code into the public domain.
3. Encountered this already, people who want Java for an obvious perl job (text manipulation) because it means they can hire any old Java programmer to maintain it. Not sure I agree with this motivation but I guess its out there:)
4. Fair enough.
Thanks for the info:) Its interesting but I find I can do 90% of what I need to do in perl..the mark of a general language perhaps?
Ok, this is Not a Troll. I honestly would like some serious opinions on Java strength, in consideration of the following points: (I use perl in a lot of these examples 'cos its my favorite language, but they apply in other cases too)
1. Portability
Ok, everyone raves about how portable Java is, but well, so is perl (interpretor on numerous platforms, bytecode compiler too)
2. Large publically available codebase
Erm. CPAN?
3. Rapid development
Ok, In my opinion, there are very few things that could be built as fast or faster in Java (by an expert Java programmer) than in perl (by an expert perl programmer). I say this for several reasons:
- Terse syntax under perl, less typing (cheap shot, but valid none the less)
- extremely flexible types mean easy reusability and a total lack of numeric problems
- Built-in high-level data structures (hashes, arrays) and the syntax to operate efficiently on them (list assignment)
4. Speed, ok, admittedly fo the most part, people maintain that java is slow. I am aware that this is considered to be a VM issue more than a language issue, however I think its worth pointing out that in many cases, the data types used most often in large applications are slow because they're written in Java. Take the classic hash for instance. Perl has it built in. C has it in a library which gets nicely compiled, C++ in a template, again compiled. Java on the other hand, has all its high level data types written in Java. An enormous performance hit considering the amount of use these kind of types get in heavy duty applications.
Now, again in my opinion, a JIT could make up for the speed issue, and I only claim that perl is plenty portable, not that it has an advantage over Java in this respect.
I am willing to concede that there is more Java code out there than perl code, but I don't believe there is so much that it makes a big difference.
This being the case, and assuming my assertion about speed of development is true, why are people using Java? What benefits do Java programmers believe they gain (technical, not $$:), as opposed to using perl, or even one of the functional langauges (ocaml was presented here, but there are others, Erlang etc, which profess even greater programmer efficiency gains than perl)
I don't disagree that C++ reduces complexity, but there are good reasons why people haven't moved to it:
1. Cost/Benefit ratio isn't great enough, there are a large number of applications already written in C, writing an app in C gives you a guarranteed audience of coders capable of working on your open source program. C++ does not reduce complexity well enough to make it work the price of losing that group of coders, and in many cases, learning C++.
2. There are better alternatives. Indeed, we are already way beyond C++ as the solution to complexity. Essentially, languages such as perl, haskell, python etc are the ones you move to if you wish to reduce complexity. They reduce it by massive degrees, not the increments that C++ does,
- they automate memory management
- they provide high level structures like associative arrays and string manipulation right there in the language
- they completely avoid pointer ops etc increasing reliability of cheap code
- they massively reduce code size by avoiding unnecesary overdeclaration
- in many cases they come with a central class archive where modules can be sourced, CPAN for perl for example
- In every non-performance-critical case, they will perform more than acceptably for the task. Additionally, the higher level definition of the task given to these interpreters leaves open long-run dynamic optimisation etc that we see being implemented in perl 6, allowing the programs to fit themselves to the use to which they are being put in any given execution, a task difficult to achieve well in lower level languages.
Essentially every argument that could suggest C++ as the better alternative to C, also suggests python as the better alternative to C++, and people are waking up to this rapidly. CPU cycles are, with the exception of games and other CPU hard tasks, no longer a resource to be carefully preserved.
Applications today need several important features:
1. Stability. It is trivial to write a stable application in perl, it is non-trivial in C or (to a lesser extent admittedly) C++
2. Adaptability. Less code = easier to refactor.
3. Easy interaction with other applications.
These are all served better by the higher-level languages available today, than they are by C or C++. By all means write your X window server in C++, or your kernel in C, but a word processor? it requires too many features too quickly and too much multi-app communication to be done effectively in C/C++. The over-long engineering times of many of todays open-source applications is due to the desire to stick to C/C++, and the DLL "hell" that many people are seeing is primarily due to attempts to create components of things that should never have been done as a shared library in the first place, but as a module in a higher level language.
Piffle. An efficient symmetric cipher does not require any additional information. Its a transformation, not an expansion. There is no need for checksums or repeated bits unless the underlying layer needs it anyway.
An asymmetric cipher is a different beast althogther and may explain why you made the comment, however asymmetric ciphers should only be used in the initial (general non-performance related) exchange in order to set up a symmetric key.
The CPU cost for decent encryption at ADSL and modem speeds, even at maximum link rate, is not particularly large, and the latency introduced is almost non-existant (we are, of course, assuming a good implementation of a good algorithm here, VOIP stream ciphers and block ciphers such as Blowfish are particularly effective).
Unfortunately, the most important point here is missed. No matter how well secured the link is, the gamer has complete control over one end of it. Therefore, with a bit of hunting around in memory, they have the encryption key, and, in fact, access to all the buffers the information is being decrypted into, and all the internal game structures.
Piffle. An efficient symmetric cipher does not require any additional information. Its a transformation, not an expansion. There is no need for checksums or repeated bits unless the underlying layer needs it anyway.
An asymmetric cipher is a different beast althogther and may explain why you made the comment, however asymmetric ciphers should only be used in the initial (general non-performance related) exchange in order to set up a symmetric key.
The CPU cost for decent encryption at ADSL and modem speeds, even at maximum link rate, is not particularly large, and the latency introduced is almost non-existant (we are, of course, assuming a good implementation of a good algorithm here, VOIP stream ciphers and block ciphers such as Blowfish are particularly effective).
Unfortunately, the most important point here is missed. No matter how well secured the link is, the gamer has complete control over one end of it. Therefore, with a bit of hunting around in memory, they have the encryption key, and, in fact, access to all the buffers the information is being decrypted into, and all the internal game structures.
I find this comment highly amusing. Your office suite makes you so productive? your GUI file managers and your bloated "word processors" and your pretty point-and-drool email clients make you productive?
I utterly disagree.
The only advantage to these shiny toys is the extremely low level of time needed to learn how to use them. Thats it, right there.
For email productivity, watch a "hacker geek" use mutt, for editing, vi or emacs or joe, for file management, a command-line, the find command, for statistics and analysis, perl, gnuplot, whatever.
The simple fact is that the "majority" you stand there and speak of is the lazy majority, those who don't use the computer as a tool, they use the computer as a shiny toy. Check this out! I can pick up my shiny toy and play with it for 10 minutes and end up with a sandcastle! joy!
Wanna build a house? take yonder "tools", the hammer, the nail, the pieces of wood. Simple aren't they? Can you build a house? don't be stupid, you could try, it'd take you ages and it'll most like fall down unless you're a builder.
Being productive, fast, effective, this requires learning, it requires an investment of time in understanding the physics of wood placement, in gaining the experience to know how much wood you need, what to hit, where, when, why.
Sure everyone and their kid sister can write a document using Word. Yay. But don't for an instant believe that these shiny toys designed specifically to allow you and your kid sister to write a document without having to invest much time is in any way "efficient".
All that code, all that bulk, all those buttons and threads, and GUIs and windows and context sensitive helpbars, are there because you need it.
You are directly responsible for the inefficiency of the software you use.
Think what this really means. It means that instead of suffering a high initial startup cost, in learning an effective and efficient method of communication with your computer, you are forever stuck with a higher-cost interface.
You cannot control your computer effectively, you cannot make it work for you as it should. If you were only going to touch your computer 10 times in your life, this would be no big deal, but the fact is that everyone is moving to computers, everything is moving to computers. You wanna do anything in an office today? you're most likely going to use a computer.
Every moment that you stand there waiting for a GUI to load, every second that you spend recovering from Windows crashing, every idle tap of the mouse that goes by as you wait for Word to load so you can send out a memo, is your wasted life.
You're dying of fear. You fear you'll break it, you fear the unknown, you fear that somehow you don't have the time to learn all that you need to learn.
You don't have a second to lose. Learn, now, quick, before you lose another second of your life to your "productivity" software.
Out of interest, something I noticed when I was working on math (simple stuff, 2nd year university style) was that there isn't a lot in the way of computer software that will validate and speed up the creation of formulae.
As a programmer, I have a vast number of tools available to speed up writing software, from cut&paste editors, to testing suites, libraries of pre-built modules for specific purposes and optimising compilers. Math doesn't seem to have much in the way of that from what I've seen, but I could be wrong.
I am aware of Maple, although I never really did a lot with it, but are there other programs doing more advanced things? the thought occurs that software in collaboration with something like MathML could create libraries of common formulae in much the same way that libraries of common software are available now, for the express purpose of making the initial creation of new formulae faster and less error prone.
Its an intriquing problem. I certainly wouldn't stake $5000 on nobody being able to compress the data I supplied, good random number generator or not. Why? because while the concept that random data in general cannot be compressed is correct, there are no patterns, it is not necessarily true that a given set of random data cannot be compressed.
For example, a file full of 0's, is perfectly possible from a true random number generator, and just as likely as any other set of numbers. As any good geek knows, a file full of 0's compresses very very well.
In this case, I think the challenge has one major problem, and that is that there is no real time limit on the entry, and no requirement that the decompressor work effectively in general, it can be entirely specialised.
This means that the problem *may* be solvable, simply by throwing ungodly amounts of CPU power at it. With the appropriate code, it would be possible to simply hunt for unintentional patterns in the data and hope. If you're lucky, there will be enough indexable patterns present that it will outweigh the cost of the indexing, and the code necessary to replace the index points.
If you're unlucky, the data will have no patterns in the space you searched, and therefore you're out of luck.
This is why the guy noted that if he got a big enough file, he could win the competition. As the filesize increases, it becomes increasingly likely that there are, accidentally, enough patterns in the data to cover the space required for the decompressor and the dictionary. Of course, as the filesize increases, you also have to burn considerably more CPU in order to locate the patterns in the first place.
Personally I think it would make an excellent project for a research team, not particularly for the money, but in order to create some really fast, specialised code for locating patterns in assumedly random data.
I am not aware of much effort in that area, most compression research goes into identifying patterns inherent in the data type, waveforms in audio, visual patterns in images, duplicate strings in text and binary files. It would be very interesting to see just how effective fast analysis code and heavy CPU is against the problem.
I suspect there may well be some crossover here with Cryptoanalysis, since one of the primary jobs in breaking crypto is finding the patterns that differentiate the ciphered data from pure randomness.
Just a note, regarding the level of plugin, the GPL does actually specify at least one point I believe, which is that code of any license can interact with it if the GPL code is entirely contained within a standalone executable or some such, I suggest a careful look around the FSF website, but examples put forward earlier such as Netscape Mail using gzip, etc, suggest that you could do it with only a little work.
Slashdot Mirror
You're so wrong it's funny :)
:) there *is* no further analysis you can make. lets take the following:
Sorry, didn't mean to mock, it's just amusing whenever these one-time pad things come up and everyone starts jumping up and down yelling "unbreakable" and others start going "no, 'cos, like, we could brute-force it.."
You can't brute-force a one-time pad. That's the point. There are many weaknesses to OTP, related to key exchange, but you can't brute force it, because you have no way of knowing if you're right, or even if you're close. The possible set of plaintexts from a properly OTP encrypted message is the complete set of possible plaintexts of that size (or smaller, plausibly).
Let us take the following ciphertext:
aaa
I have encrypted this with a one time pad. Now, it's a pretty short message. We could brute force all the possible combinations on your regular computer pretty much instantly. Anyone care to guess what the message might be?
Of course not, because it could be *any* 3 letter combination, assuming that I'm sticking to letters. Any attempt to contextually analyse it is flawed because you will never be able to prove you got it right. Let's say that we know the message is english, and we can therefore reduce the number of possibilities down to all 3 letter english words.
Woohoo. It doesn't help, it doesn't get us any closer to knowing exactly what it is, because there is no next step, the only information that can aid us in the decryption of a one time pad is information from "outside" the decryption. In this case, two items of information are available to us, the length (3 letters) and the fact that it is english, but the actual ciphertext itself is of no value whatsoever. It doesn't matter if those a's were z's or q's or anything else, we can't do anything with them unless we have the OTP.
"Decrypt candidates with "bad" and "moo" in them would definitely merit further analysis"
This is always the point where things go wrong
abskjhsglkjlssdkglkjsfdlkgjfld
Now lets imagine that we knew it was coming from bank robbers. Sweet, so, what can we do? again, the *only* information we have is the length. It could say this:
I am going to rob a bank in WA
Or this:
I am going to rob a bank in CA
Or this:
I am going to rob a bank in NZ
And there is no way to prove what it actually says at all. It might say:
I am going to buy some flowers
Again, you'll never know unless you have the key, there's just no way to tell.
Intriguing. I guess your situation wasn't that different from mine (http://exorsus.net/), but I started out with very few people as part of the collective (3 of us in fact), and the bills were never very high anyway, so, we're still a collective, kinda. different people have paid the bills at different times, sometimes me only, sometimes me and up to 4 others, right now just me and one other guy, but it has worked out nicely. Never be a business tho.
Brief elaboration: if you apply for a patent, you have to disclose your innovation to the state. But you don't have to apply for a patent, so this isn't seizure as much as it is a trade: you give up ownership of your property later for legal protection by the state today. But copyrights are different. You don't have to apply for copyright protection; every written work gets it automatically. This is the good part. But that copyright protection expires (!!) after a time, at which point the author's property rights are revoked and his property is seized by the state. How would you feel if your house only belonged to you for 20 years, after which time you'd have to give it to the state? Property doesn't work like that in our culture. The idea of "the commons" is almost always invoked to refer to the idea that somehow property isn't really property, and that everything really belongs to the state, or "the commons." It's used to justify seizure of property by invoking a high-minded notion of greater good.
Nono, Copyright is a trade too. In return for the right to sue via the courts for breach of copyright, you have to eventually give it up. This is not seizure, because you don't have to give it up at all, you can not tell anyone and it will be yours forever.
That is the equivalent to a house. You do not own ideas or works, you own your brain and your house and your computer. While your ideas are in there, they are yours. When they are released, by general agreement you recieve the right to determine how they are distributed for 20 years, because it was seen at the time as impetus to release ideas. But you don't own the idea.
Nothing is taken from you that was not given to you in the first place when copyright expires.
> You'll have to explain to me how that's easier than dragging the application out of the DMG file into the Applications folder.
It's much easier. You don't need to know where to get the application, you don't need to go download the DMG file. Everything done for you, just type "apt-get install mozilla" and wait. Local mirrors of everything for added speed.
In addition, it takes care of dependencies (although I acknowledge that the Apple mechanism of "One-file-for-the-app" is a good alternate solution to this a lot of the time), and allows you to go and upgrade any or all installed applications without having to remember where you got it, go and find it, download it again etc etc.
Even further, you can do full searches of available applications using apt-cache, allowing you to quickly and easily locate, for example, and mp3 player or a video encoder immediately available for installation.
APT really is very very good. All kudos to Apple for many of their usability features, but in this one area Debians devotion to Free software has given it leverage which has proven difficult for other operating systems to match, a supply of almost all the software you'll ever need on your system, right here, right now.
> The number of the modding shall be three, four shall the number of the modding not be, neither shall it be 2...
You fools! five is right out!
Most people here have said something interesting and on the point, but few seem to have put them all together. The point is whether Mozilla is Open or Free. We keep mixing these terms up because in many instances, to us as progammers, they're pretty interchangable.
However in something like this, there's actually a big difference. For something that is Open Source, protecting the trademark makes sense. The project has an identity and there is no reason why that identity shouldn't be protected. This may place restrictions on changes or use of material, but the *code* is still there, still changable, still redistributable.
For something that is Free Software however, its completely different. The objective here is not identity, even with the GNU/Linux calls. The objective is Freedom as in Speech, to do as you wish with the software so long as you grant others the same freedom. It's no good for the original author to have more freedom than other contributors, in the software or in the naming or in anything. The key to quality should not be "what it is", but "who it came from". The "source", from program code to vector graphics files for the logos and buttons to anything else appropriate should be available so that anything the user wishes to change can be changed.
And this is why it's an issue for the Debian group. They're really into Free, they like Free and for Debian, Free is definitely the preferance since they make a number of changes on many projects to help them fit into the distribution as a whole better.
Of course, people will do bad things. Don't ever be under the illusion that Free or Open things always improve. Sometimes, someone does something almost terminally stupid with a project. The point, however, is that nothing is *lost*. The original is still there, and if the reputation concept works, the best will float to the top from collective experience.
So don't get annoyed when Debian screws something up and mozilla gets bug reports. It's going to happen, the only way to prevent it, will prevent the benefits you get as well, and the benefits outweigh the downsides by a staggering degree. Lets not get too fussed and throw the baby out with the bathwater (or the email out with the spam if you prefer). We can deal with this kind of thing in ways other than removing our freedom.
I think its quit clear that there are a suspicously low number of unexplained explosions, leading me to conclude that explanations for many explosions are bogus and therefore that there are many strangelets hitting the earth every year and a concerted effort to cover this up to avoid insurance hikes.
Except that, in the US, no lunatic would ever enter a house with a knife. He'd take a gun, possibly a semi-automatic, because he'd be pretty sure you'd have one. Thus, instead of having a badly injured family who may well survive with medical assistance, you have a family who have been well and truely killed by high-velocity pieces of lead.
Escalation does not apply only to nuclear weapons.
iptables
iproute2
And yes, I fit both of them, plus a 2.4 kernel, on a 1.44mb floppy with no special formatting or anything. Admittedly it was a custom assembly but it was more than worth it for the advantages that these applications offer.
P/Invoke
More windows-only hooks than you can shake a large stick at, all in one command.
Believe it :) I'm posting from it.
Its gig ether on a (generally) switched network. You can purchase 10, 100 or gig endpoints from citylink. More details are available on www.citylink.co.nz.
Ironic that here in the middile of tech obsession nobody has thought about trying to get software to solve these financial issues.
The reason the Slashdot guys don't know what they'd charge for a subscription is because they don't know. They can't know. Any value that they choose is going to be based on several factors over which they have no control:
1. The number of people who will actually subscribe
2. The number of people who will leave
3. The number of people who will continue reading slashdot with ads
4. The number of people who will continue reading slashdot with ad blockers
5. Price of bandwidth and hosting
6. Banner ad cpm value
In addition to that, there are factors over which they have limited control:
6. Amount of bandwidth used
Put that all together and in the human world you have what is called a hunch, or a guess, or any other term which indicates that you really have no idea and everything could go to shit inside of 5 minutes.
The natural human solution to this is to look at near-worst-case scenarios and attempt to budget for that happening. The best people at this are in the insurance industry. These are called Damn Good Guesses, but they're still guesses.
The major problem with the future is that the further into the future you look, the less accurate your guess is likely to be. Guessing banner ad prices 20 seconds from now, armed with current prices, isn't a big risk, and you're not likely to be off by much even if you get it wrong. Guessing 2 years from now is near impossible.
So what we need is a way of taking all the unknown variables and guessing rapidly, in short increments, using good solid math principles, in order to determine the value of those variables we do control (cost of subscription, bandwidth to release).
In essence, a floating, self-insuring market run by a well written software agent that would take account of the various costs, the insurance probabilities involved in failed predictions, and how well it can limit the release of bandwidth, and set subscription prices based on that.
Effective tools placed in the hands of users would then let them take advantage of this by limiting the value range within which they are willing to subscribe, and see transparently the decisions being made by the software and the basis for these.
Essentially creating a resubscription process in which users automatically resubscribe every day or maybe even hour or less, and in which the code is open and its behaviour displayed for those who wish to look, it can act in the best interests of both the site, the owners and the users, keeping prices at their lowest practical point while still making a set amount of money for the owners, covering the bandwidth costs and insuring the site against price shocks in the future.
There is the technical expertise around to achieve something like this, and I think Slashdot is a perfect testing ground for this kind of software. The combination of a couple of hot-shot financial guys and a bunch of good programmers could provide software that could keep any number of valuable internet sites afloat in a world so volatile that any number of valuable sites are falling down due to bad guesses on the part of their management.
I would try it, but the only release for linux appears to be 3.02, and they've released v4.0 now, not to mention the next generation Studio product. Whats with that?
The code necessary to resolve this problem is literally a 4 line patch to openssh. I'm not kidding, I did it myself, they even have comments in most of the places you need to put it. I added a -z option which creates randomised network noise, uses from 400 to 1200b/s of packets that look just like password character packets. The support is in the protocol already, it requires no modifications to sshd, and it works fine. The only issue is the additional use of bandwidth.
This, of course, is the problem that everyone is interested in. Its an easy problem to solve, 4 lines, but not an easy problem to solve nicely, in a way that won't result in an increase in the amount of bandwidth used by an ssh application.
I don't believe its really worth worrying about. If you're really paranoid, you should add a patch like mine or run over freeswan or something. In general, its not a script-kiddie vuln.
Thanks for the info :) Lots to think about.
1. I agree, I would love to give this a go with perl though (pure perl), it would be interesting to see whether it copes as well.
:)
:) Its interesting but I find I can do 90% of what I need to do in perl..the mark of a general language perhaps?
2. Yeah, lots of people seem to have jumpedon the java bandwagon and dumped code into the public domain.
3. Encountered this already, people who want Java for an obvious perl job (text manipulation) because it means they can hire any old Java programmer to maintain it. Not sure I agree with this motivation but I guess its out there
4. Fair enough.
Thanks for the info
Thankyou. God knows why you got flamebaited, some good info. I will investigate OCaML for my own enlightenment :)
Ok, this is Not a Troll. I honestly would like some serious opinions on Java strength, in consideration of the following points: (I use perl in a lot of these examples 'cos its my favorite language, but they apply in other cases too)
:), as opposed to using perl, or even one of the functional langauges (ocaml was presented here, but there are others, Erlang etc, which profess even greater programmer efficiency gains than perl)
1. Portability
Ok, everyone raves about how portable Java is, but well, so is perl (interpretor on numerous platforms, bytecode compiler too)
2. Large publically available codebase
Erm. CPAN?
3. Rapid development
Ok, In my opinion, there are very few things that could be built as fast or faster in Java (by an expert Java programmer) than in perl (by an expert perl programmer). I say this for several reasons:
- Terse syntax under perl, less typing (cheap shot, but valid none the less)
- extremely flexible types mean easy reusability and a total lack of numeric problems
- Built-in high-level data structures (hashes, arrays) and the syntax to operate efficiently on them (list assignment)
4. Speed, ok, admittedly fo the most part, people maintain that java is slow. I am aware that this is considered to be a VM issue more than a language issue, however I think its worth pointing out that in many cases, the data types used most often in large applications are slow because they're written in Java. Take the classic hash for instance. Perl has it built in. C has it in a library which gets nicely compiled, C++ in a template, again compiled. Java on the other hand, has all its high level data types written in Java. An enormous performance hit considering the amount of use these kind of types get in heavy duty applications.
Now, again in my opinion, a JIT could make up for the speed issue, and I only claim that perl is plenty portable, not that it has an advantage over Java in this respect.
I am willing to concede that there is more Java code out there than perl code, but I don't believe there is so much that it makes a big difference.
This being the case, and assuming my assertion about speed of development is true, why are people using Java? What benefits do Java programmers believe they gain (technical, not $$
I don't disagree that C++ reduces complexity, but there are good reasons why people haven't moved to it:
1. Cost/Benefit ratio isn't great enough, there are a large number of applications already written in C, writing an app in C gives you a guarranteed audience of coders capable of working on your open source program. C++ does not reduce complexity well enough to make it work the price of losing that group of coders, and in many cases, learning C++.
2. There are better alternatives. Indeed, we are already way beyond C++ as the solution to complexity. Essentially, languages such as perl, haskell, python etc are the ones you move to if you wish to reduce complexity. They reduce it by massive degrees, not the increments that C++ does,
- they automate memory management
- they provide high level structures like associative arrays and string manipulation right there in the language
- they completely avoid pointer ops etc increasing reliability of cheap code
- they massively reduce code size by avoiding unnecesary overdeclaration
- in many cases they come with a central class archive where modules can be sourced, CPAN for perl for example
- In every non-performance-critical case, they will perform more than acceptably for the task. Additionally, the higher level definition of the task given to these interpreters leaves open long-run dynamic optimisation etc that we see being implemented in perl 6, allowing the programs to fit themselves to the use to which they are being put in any given execution, a task difficult to achieve well in lower level languages.
Essentially every argument that could suggest C++ as the better alternative to C, also suggests python as the better alternative to C++, and people are waking up to this rapidly. CPU cycles are, with the exception of games and other CPU hard tasks, no longer a resource to be carefully preserved.
Applications today need several important features:
1. Stability. It is trivial to write a stable application in perl, it is non-trivial in C or (to a lesser extent admittedly) C++
2. Adaptability. Less code = easier to refactor.
3. Easy interaction with other applications.
These are all served better by the higher-level languages available today, than they are by C or C++. By all means write your X window server in C++, or your kernel in C, but a word processor? it requires too many features too quickly and too much multi-app communication to be done effectively in C/C++. The over-long engineering times of many of todays open-source applications is due to the desire to stick to C/C++, and the DLL "hell" that many people are seeing is primarily due to attempts to create components of things that should never have been done as a shared library in the first place, but as a module in a higher level language.
Piffle. An efficient symmetric cipher does not require any additional information. Its a transformation, not an expansion. There is no need for checksums or repeated bits unless the underlying layer needs it anyway.
An asymmetric cipher is a different beast althogther and may explain why you made the comment, however asymmetric ciphers should only be used in the initial (general non-performance related) exchange in order to set up a symmetric key.
The CPU cost for decent encryption at ADSL and modem speeds, even at maximum link rate, is not particularly large, and the latency introduced is almost non-existant (we are, of course, assuming a good implementation of a good algorithm here, VOIP stream ciphers and block ciphers such as Blowfish are particularly effective).
Unfortunately, the most important point here is missed. No matter how well secured the link is, the gamer has complete control over one end of it. Therefore, with a bit of hunting around in memory, they have the encryption key, and, in fact, access to all the buffers the information is being decrypted into, and all the internal game structures.
You just can't trust the client.
Piffle. An efficient symmetric cipher does not require any additional information. Its a transformation, not an expansion. There is no need for checksums or repeated bits unless the underlying layer needs it anyway.
An asymmetric cipher is a different beast althogther and may explain why you made the comment, however asymmetric ciphers should only be used in the initial (general non-performance related) exchange in order to set up a symmetric key.
The CPU cost for decent encryption at ADSL and modem speeds, even at maximum link rate, is not particularly large, and the latency introduced is almost non-existant (we are, of course, assuming a good implementation of a good algorithm here, VOIP stream ciphers and block ciphers such as Blowfish are particularly effective).
Unfortunately, the most important point here is missed. No matter how well secured the link is, the gamer has complete control over one end of it. Therefore, with a bit of hunting around in memory, they have the encryption key, and, in fact, access to all the buffers the information is being decrypted into, and all the internal game structures.
You just can't trust the client.
I find this comment highly amusing. Your office suite makes you so productive? your GUI file managers and your bloated "word processors" and your pretty point-and-drool email clients make you productive?
I utterly disagree.
The only advantage to these shiny toys is the extremely low level of time needed to learn how to use them. Thats it, right there.
For email productivity, watch a "hacker geek" use mutt, for editing, vi or emacs or joe, for file management, a command-line, the find command, for statistics and analysis, perl, gnuplot, whatever.
The simple fact is that the "majority" you stand there and speak of is the lazy majority, those who don't use the computer as a tool, they use the computer as a shiny toy. Check this out! I can pick up my shiny toy and play with it for 10 minutes and end up with a sandcastle! joy!
Wanna build a house? take yonder "tools", the hammer, the nail, the pieces of wood. Simple aren't they? Can you build a house? don't be stupid, you could try, it'd take you ages and it'll most like fall down unless you're a builder.
Being productive, fast, effective, this requires learning, it requires an investment of time in understanding the physics of wood placement, in gaining the experience to know how much wood you need, what to hit, where, when, why.
Sure everyone and their kid sister can write a document using Word. Yay. But don't for an instant believe that these shiny toys designed specifically to allow you and your kid sister to write a document without having to invest much time is in any way "efficient".
All that code, all that bulk, all those buttons and threads, and GUIs and windows and context sensitive helpbars, are there because you need it.
You are directly responsible for the inefficiency of the software you use.
Think what this really means. It means that instead of suffering a high initial startup cost, in learning an effective and efficient method of communication with your computer, you are forever stuck with a higher-cost interface.
You cannot control your computer effectively, you cannot make it work for you as it should. If you were only going to touch your computer 10 times in your life, this would be no big deal, but the fact is that everyone is moving to computers, everything is moving to computers. You wanna do anything in an office today? you're most likely going to use a computer.
Every moment that you stand there waiting for a GUI to load, every second that you spend recovering from Windows crashing, every idle tap of the mouse that goes by as you wait for Word to load so you can send out a memo, is your wasted life.
You're dying of fear. You fear you'll break it, you fear the unknown, you fear that somehow you don't have the time to learn all that you need to learn.
You don't have a second to lose. Learn, now, quick, before you lose another second of your life to your "productivity" software.
Out of interest, something I noticed when I was working on math (simple stuff, 2nd year university style) was that there isn't a lot in the way of computer software that will validate and speed up the creation of formulae.
As a programmer, I have a vast number of tools available to speed up writing software, from cut&paste editors, to testing suites, libraries of pre-built modules for specific purposes and optimising compilers. Math doesn't seem to have much in the way of that from what I've seen, but I could be wrong.
I am aware of Maple, although I never really did a lot with it, but are there other programs doing more advanced things? the thought occurs that software in collaboration with something like MathML could create libraries of common formulae in much the same way that libraries of common software are available now, for the express purpose of making the initial creation of new formulae faster and less error prone.
Its an intriquing problem. I certainly wouldn't stake $5000 on nobody being able to compress the data I supplied, good random number generator or not. Why? because while the concept that random data in general cannot be compressed is correct, there are no patterns, it is not necessarily true that a given set of random data cannot be compressed.
For example, a file full of 0's, is perfectly possible from a true random number generator, and just as likely as any other set of numbers. As any good geek knows, a file full of 0's compresses very very well.
In this case, I think the challenge has one major problem, and that is that there is no real time limit on the entry, and no requirement that the decompressor work effectively in general, it can be entirely specialised.
This means that the problem *may* be solvable, simply by throwing ungodly amounts of CPU power at it. With the appropriate code, it would be possible to simply hunt for unintentional patterns in the data and hope. If you're lucky, there will be enough indexable patterns present that it will outweigh the cost of the indexing, and the code necessary to replace the index points.
If you're unlucky, the data will have no patterns in the space you searched, and therefore you're out of luck.
This is why the guy noted that if he got a big enough file, he could win the competition. As the filesize increases, it becomes increasingly likely that there are, accidentally, enough patterns in the data to cover the space required for the decompressor and the dictionary. Of course, as the filesize increases, you also have to burn considerably more CPU in order to locate the patterns in the first place.
Personally I think it would make an excellent project for a research team, not particularly for the money, but in order to create some really fast, specialised code for locating patterns in assumedly random data.
I am not aware of much effort in that area, most compression research goes into identifying patterns inherent in the data type, waveforms in audio, visual patterns in images, duplicate strings in text and binary files. It would be very interesting to see just how effective fast analysis code and heavy CPU is against the problem.
I suspect there may well be some crossover here with Cryptoanalysis, since one of the primary jobs in breaking crypto is finding the patterns that differentiate the ciphered data from pure randomness.
Any links appreciated.
Just a note, regarding the level of plugin, the GPL does actually specify at least one point I believe, which is that code of any license can interact with it if the GPL code is entirely contained within a standalone executable or some such, I suggest a careful look around the FSF website, but examples put forward earlier such as Netscape Mail using gzip, etc, suggest that you could do it with only a little work.