You assume that a "sender" (an identity) is a limited resource. If we have true identities (one person, one identity), then using identitity fractions or rate limits per identity as your limiter (as you suggest) works. However, enforcing this identity mapping is quite difficult, and in general requires that we base identity on some other scarce resource, for instance having a physical body and presenting it to some trusted authority. This is quite ackward. We do, however, already have various systems in place for handling money, and it is (by design) a scarce resource. Money can be handled without identity in the moment - examples abound, from use-once credit card numbers for net purchases through Swizz and Austrian numbered bank accounts, visiting anonymous pre-paid cellular phones and ending up in normal hard cash.
As for signatures: Yes, you need one signature per combination of recipient and message - I tried to communicate that in the protocol description (by describing the recipient address as part of the message), but it obviously didn't work out communication-wise:-(
I'll return the first sentence from the previous post: 'How does nonsense like this get modded up as "Insightful"?'
Enforcing "charge per e-mail" and enforcing "you cannot spam" is not technologically the same at all.
Charging for e-mail can be implemented with digital cash, A trivial scheme for this is as follows (for Alice sending an e-mail to Bob, with Trent acting as a trusted third party. In practice, each of these would be done by a computer, and you'd want a more complex scheme that allows Bob to finally get the money instead of Trent):
Alice writes her e-mail.
Alice computes a checksum of the e-mail and the recipient address she wants to send it to.
Alice present this checksum to Trent, along with some money (payment for the mail).
Trent use public key cryptography to sign the checksum, basically saying "I certify that somebody have paid me to send this e-mail". Note that Trent cannot tell the contents of the e-mail - he only see the checksum.
Trent gives the signature to Alice
Alice send the e-mail along with Trent's checksum to Bob.
Bob computes the checksum on the mail (including destination address)
Bob checks that Trent's signature match that checksum.
Bob accepts the mail.
Now, if Mallory (a spammer) want to send a mail, she has to pay Trent. Unless she pays Trent, she won't get his signature, and Bob won't accept her mail.
Thus, the problem of trusting "all the people on the Internet" reduces to trusting the people that are supposed to take payment before signing - and these should be way fewer than the number of people on the Internet.
The above scheme also keeps privacy for the mail sent - the only potential lack of anonymity is for the sender, who needs to pay Trent somehow. This is, however, a separate issue.
Enforcing the rule "You may not spam" is a totally separate issue. It can't be done without checking whether the e-mail in question is spam.
This means either:
That the sender of all e-mail has to be physically identified with a particular physical individual (which means going to the police station to identify yourself to get an "e-mail-pass"), a working complaint system (which would basically be the courts), and a working system for dealing out punishment ("Our troops are going to invade your country because one of your citizens sent commercial e-mail to people that did not want it!").
That each e-mail must be read through and approved by somebody as not being spam before being sent.
Neither of these seem particularly realistic.
Note that the payment system described was designed to be as simple as possible. It was just made to put down the argument in the parent. If I was to design a system for actual use, I would do a protocol that led to Bob getting the money in the end (instead of Trent), among other things. I'm fairly certain this this is possible, but it definately require more complexity than I wanted in the example.[1]
Eivind.
[1] The problem is keeping Bob anonymous while not having any post-receive enforcement possibilities against Alice. If it is OK to identify to Trent that Bob has gotten an e-mail without identifying that it is from Alice, this can be done by having Trent do a blind signature on a checksum + Bob's key, and then have Alice unblind it and let Bob present the signed packet to Trent for collection. If post-fact enforcement against Alice was possible, we could use traditional offline Digital Cash schemes.
The previous post miss out on many aspects of algorithmic optimization, and lead to the wrong conclusions.
For a better analysis of optimization in this specific part of the sort space, I recommend Jon Bentley's classic "Engineering a sort function".
This paper discuss how to implement an optimal sort, after having done real-life measurements. Conclusions include dropping to an O(N^2) sort algorithm when qsort partitions become small enough - insertion sort was choosen. (The selected cut off was secven elements at that point; it may be that it would be sensible to choose a higher cutoff for the generic case now, as the cache locality might help. However, I won't bet on this either way without doing measurements.)
The qsort implemented there is the one still used in at least FreeBSD. I don't know the status for other OSen.
As for big O notation: The discussion in the previous post is so imprecise as to be misleading. It use "cost" and "complexity" where it discuss asymptotic complexity; these are distinctly different, and it is necessary to be quite clear on the distinctions to do correct analyses.
Big-O notation measure asymptotic complexity over an arbitrarily selected set of basic operations assumed to have unit cost. It discard all constants to make the analysis easy to do and easy to work with. This is a useful tool, but it only measure asymptotic complexity, and it only does it based on arbitrary basic operations.
In practice, a mere factor 1000 speed difference (one second to twenty minutes) might be quite noticable. This will be REMOVED from the big-O analysis, which can make it point in a quite different direction from the truth.
In the parent post, sorting 1000 elements is assigned a unit cost, claiming that the time will be similar for a bubble sort and a quick sort, and "low enough not to matter". Further, the conclusion is "never use bubble sort". Assuming a naive implementation of both bubble sort and quick sort, and a set of arrays that is already sorted, the quicksort will be O(N^2) and the bubble sort will be O(N) in the number of items in each bin. This is a quite noticable difference in asymptotic complexity.
A naive programmer is in my opinion the only relevant assumption if we're to give absolute advice on simple sort functions. A non-naive programmer will know how to do complexity evaluation, will know the tradeoffs on startup of the various algorithms, and will only be implementing a sort him- or herself because actual speed measurements or specific knowledge of the sort behaviour show that the system supplied sort is not fast enough for the case in question, and that a custom sort can do better. (S)he will also evaluate whether the data to sort is likely to be almost sorted or highly random, and thus which kind of algorithm is likely to go faster. (And insertion sort/bubble sort is actually faster also for large data sets if they're almost sorted beforehand.)
Eivind, who if he had to give general advice would give "evaluate qsort, mergesort, heapsort, insertion sort, and using a data structure that keeps order before choosing bubble sort."
Re:Joe vs. vi vs. GUI based editors
on
JOE Hits 3.0
·
· Score: 5, Informative
Why am I "married" to command line editors? There are really two reasons: Flexibility of context for use, availability in the context I am, and the price of screen real estate.
I'll address these in opposite order (which I think may be in reverse of priorities, but I'm not sure):
A plain xterm with a minimal border takes less screen real estate than a GUI editor. Screen real estate is a limited commodity - I'll do more or less anything to get more space for what I'm actually working on instead of decorations. And what I'm working on is the text I'm editing, not the buttons and menus that sit there.
A "command-line-based editor" (started from command line and run in the same window allows me to edit a file *in the same visual context as I already was*. This means that I have less of context change than if I either start a new window or use an editor launcher to get a buffer in an already running editor.
And finally, a terminal-based editor gives me flexibility to use the same editor in most contexts I use an editor. I can run it in a console to fix up a config file on a machine that hasn't got X yet, I can run it remotely on a server that isn't supposed to have X installed, I can run it on a remote machine I don't trust to have an X connection to my box (as an X connections allows keyboard snooping), I can run it when I sit on a Windows box with no X and should fix an issue with a server for a customer that use Windows desktops and Unix servers, I can run it when there is enough latency for X to be a pain, I can run it against servers where an X based editor takes too much resources (yes, these exists - for instance, I'd feel bad about running an X based editor on the FreeBSD.org servers, for resource reasons), etc, etc, etc.
Basically, there are a couple of direct UI advantages to terminal based editors compared to X based editors, as well as there being a lot of times it just isn't feasible to run an X editor. Until an X editor in itself is noticably better than the terminal based editors (and that day may come, but I don't know of any X based editor that is clearly better) people like me will keep running only terminal based editors, instead of running an X based editor with a side-dish of a *different* terminal-based editor whenever we can't run the X-based one.
As one gets older, and people pair off, friendships with the opposite sex decline and fade. I've lost some of my best friends in recent years.
That's not necessary - it's a question of where you aquire your new friends. I've been getting female friends continually (and I'm 29 now).
However, at the moment I'm specifically trying to avoid female friends I don't sleep with, as I'm working on up'ing pickup skills. When I'm with female friends, I get positive feedback on behaviour that results in getting female friends - which is NOT the same as the behaviour that result in getting lovers.
My final comment about "poor design" is this. Assuming the design is poor, does it really matter? If it solves problems, and if people use it, and it is a Good Enough solution, and if the price is right, poor design is largely unimportant, right?
In a way. The question is "What is good enough?" and "Solves what problems how well?". For me, the design problems in a lot of commonly used software (MySQL, perl, the pre 2.6 Linux VM, autoconf, the FreeBSD mergemaster tool, the Windows registry, the language SQL,...) have bitten me, and in some cases keep biting me on a daily and weekly basis.
Of course, each of these have strengths that have made them be major players in their niche in the first place. This include
Being available at the right time (here simplicity of design helps)
Working stably according to documentation (here simplicity of design helps)
Making the user feel (s)he can "grasp" the system completely (and here simplicity and obviousness of design choices helps immensely)
Ease (or perceived ease) of starting to use the product
It continutally being (perceived to be) cheaper to work around the flaws of the product than to switch to another product
Having enough problems that people ask around about the product, thus creating "buzz", without these problems being fatal or being perceived to be the product itself.
Having enough problems that people feel an emotinal investment in the product (and keeping each investment small enough) that the cost of switching is overestimated. ("I've spent hundreds of hours working out small quirks that are Linux-specific, and now you want me to switch to a different system? NO WAY!")
Having legacy code available, so working around the flaws are still cheaper than re-implementing or migrating (at least with a day-to-day perspective)
Note that I do explictly NOT list being a more efficient or better system overall. People are generally reluctant to take any larger investment of time than they have to, even if that increase overall productivity. The gains have to be perceived as large and fairly immediate before taking the time investment.
So - in my evaluation, "poor design" is important. It gives continious costs *and those costs tend to emotionally bind the users to the product with the flaws*. However, poor or good design is not important to whether a system gets adopted or not. , if it isn't so horribly bad that this is immediately obvious.
And to get back on topic: With MySQL, what I really hate is that it make up data in order to make sure inserts pass. This has made much more trouble for me than any of the other issues - the other issues are easy (though a lot of work) to work around and keep in mind, but accepting bad data requires a ton of verification at the DB-interface layer of the application - and this is non-obvious, and have not been implemented in a lot of code I have had to work with:-(
Actually I'm not a direct subcontractor - my employer (ThinkSec) is, but I will be the person mostly working on it, playing ball with my coworker and fellow FreeBSD committer, Dag-Erling Smørgrav, as appropriate.
But isn't IFS under a restrictive license already?
(I'm assuming you mean "IPF" as in IPFilter) Well, it is in a sort of twilight zone. The original license can be read either way, and the way most people have read it has been different from what Darren intended with it. And this is the reason why IPFilter has been allowed into the base (along with Darren not saying anything about it, while he should be perfectly aware of the *BSD license policies, as he has a commit bit in both FreeBSD and NetBSD.)
We are looking at how to resolve it, with either Darren changing the license terms or IPFilter being delegated to a port.
Unfortunately, integrating netfilter isn't a real option. *BSD policy is that we do not want to add code that is under a restrictive license (e.g, the GPL) without it giving overwhelming functionality advantages and isn't a core component for a working system. I suspect netfilter of failing both these tests:-(
Unless the netfilter developers make sure to contact all relevant contributors and get an OK for distributing under alternative licensing (ie, BSD style licensing), at least FreeBSD will stick with ipfw (which, contrary to the LWN article, is the primary firewall used in FreeBSD.)
Eivind, FreeBSD developer, speaking his own opinions.
[On the idea of this being a hole introduced by rouge engineers, rather than Microsoft corporate policy]
Get your head out of the sand, please.
I believe, as the poster you replied to, that this isn't corporate policy. Not because MS says so (MS has close to zero credibility in my eyes), but because the backdoor was so stupidly executed. MS has a lot of good engineers - if this had been an official policy, it would have been nicely executed, and if uncovered would look just another random security hole. It would probably even be harder (but more reliable) to exploit than the non-intentional ones!
Admit it. You did it to show off; you got off on the feelings of superiority you felt when they weren't
interested in what you were interested in. Of course, you didn't share their interests, but that's
different, because they're morons and you're a genius.
This shows lack of comprehension. I used to (and still do) read similar texts because I enjoyed it, from about 3rd grade and onwards. If I was somewhere I needed to kill time, I usually tried (and try) to bring some technical/academic text (computers, science, business,...) and some fiction - as what I want to read depend on my mood. However, all of it is for my own enjoyment, not to show off.
As to not showing interest in what other people are interested in: As a teenager, you are by necessity overfocused on your interests - because you have not yet got the background necessary to handle a spread of interests. There just hasn't been enough time to learn that many sides of how the world works to a sufficient level of detail (at least not with the amount of focus most of us are able to produce.)
[On the public screwing up the stock market] How did they the uneducated public "really screw things up?" They invested in
things that looked promising (the internet,) and got burned when the profit models
were exposed as bad ideas (by the lack of profits.) So what got screwed up? The
markets continue to buy and sell stock.
By pushing the stock market up to an immense bubble due to overinvesting in tech stock, similar to what was done with railroads in the mid-1800s, radio in the 1920s (remember the bust of october 29th 1929?), and various other tech waves at other points. There's presently a few trillions of dollars too much in the public stock market compared to discounted future earnings; if any of the old patterns hold, these will need to go over time - and will possibly go as a very sharp drop.
Presently the value of the US stock market is larger than the GDP - while historical data shows it as always regressing towards a value of 50% of the GDP, with large swings on each side.
What on Earth have you been smoking Roblimo? What makes you think that the War on Drugs is nothing more than a silly game? For the millions of people whose families have been torn apart through the destructive nature of drugs, trivializing their plight is hardly sensitive is it?
Nice attempt at emotional manipulation.
I'm probably in one of those families you consider to have been "torn apart by drugs." My stepbrother was an addict for over half a decade. However, as far as I can tell, the problems we've had with him has been due to drugs being illegal. He's been pulled into a scene of criminals, have been chasing after fast money, and have been drugged out of his mind - as a feedback loop from the stress of that scene.
With drugs legal, he might still have taken them, and still have taken them to excess - but he would have done it without trying to earn money off drug deals, without having people after him to crush his kneecaps because he owed them money, without threaths to his family - and would be likely to have had a much better chance of being eased back into society, instead of having to almost die from it before ending up in a rehabilitation program.
As an interesting case in point, suicides in the Netherlands is the lowest in Europe - considered to be due to people that are desperate smoking themselves out of the world for a period, instead of dying.
And aspirin kills more people annually than cocaine, while alcohol-related deaths in the US is at 10 times the number of deaths related to illegal drugs (approx 150,000 vs 15,000 if you use the same way of counting - I just looked it up.)
Yes, the drugs that are presently illegal often waste parts of people's lives. By keeping them illegal, they waste larger parts of the lives, and in more extreme ways - for a possible reduction in the number of people that try them. Useful, isn't it?
For every small company that can't make money writing GPL software, there are 500 that can make money by using it. It saves a lot of money at my work that I can use perl for my scripting, apache for my webserver, and php for additional web stuff.
Perl is under the artistic license, lately dual licensed with the GPL. Apache is under an extended BSD license. PHP is under an extended BSD license. 0.5 out of 3 isn't so bad (though the available artistic licensing of perl makes the GPL fairly irrelevant.)
I can get these items at no cost and I don't have to worry about them ever disappearing off the face of the earth, while MS can do what they please. So tell me again how this benefits MS and how this is killing companies?
I'm going to take these in opposite orders:
How does the availability of free, copylefted software kill companies?
There are two sides to this, both of which are results of economic changes. The first is that some types of software becomes available at close to zero cost along with the benefit of the ability do easy codechanges, outcompeting higher priced proprietary software. This is good; the workforce and capital of the companies are redirected to other places where they can contribute more to society.
Then there is the second, dark side: Copylefted software block economic models which give groups of end-users choice and tweaking for their needs.
In a proprietary environment, a development company can do changes to source code as an investment, based on how many more people they expect to be buying the software based on the changes they do. For a copylefted product, the changes needs to be paid for by the first comer(s).
This is easier to see in a scenario description. There are two cases here: Market dominated by proprietary or BSDLed software, and market dominated by GPLed software. BSDLed/proprietary are fairly equal for this scenario; either the company has the maintained codebase available for proprietary use because it is being maintained due to market income, or it has the codebase it can use available due to open source maintenance. (Codebases can also be available with royalties due to commercial licensing; this gives similar cases with more complications.)
Let's set the cost of developing the codebase in the first place at $500,000,-. Let's further say that a particular new feature has a value of $100 for 1000 users, and that the cost of developing the feature is $10,000,-.
In a proprietary or BSDLed environment, this means that the company can develop the feature and sell it for anywhere below $100,000,-, while still both giving value to each customer. $90,000,- is available as cost/benefit difference, and up to this amount can be taken out as profit by the comapny while still adding value to society. This is enough available profit that it is reasonable to take the intial risk. Thus, the customers get their feature and the company get profit and everybody is better off (likely also the open source codebase, due to the distiction between strategic and tactical changes[1].)
Now for the GPLed case. There isn't a codebase available for the company to do properiary changes to, ao it has to develop that before going on to the profit side. Whoops, there was a $500,000,- cut of their $90,000,- potential profit - that's a $410,000,- loss. No way they are going to give those users the feature.
Well, what about the users themselves? Can't they just pay for the change to be incorporated into the GPLed codebase?
For each individual user, this is a loss. Paying directly to have the feature incorporated is a 100x cost increase compared to the benefit gotten back - not interesting.
Paying as a group is theoretically possible, but fraught with problems[2]. First, you need to get hold of the people in the group and get them to agree about what they need, and agree to pay for something they haven't seen, and which they will get no matter if *they as single entities* pay or not. Second, the cost of development will likely be higher. The developer in the proprietary example gets his profit from a fairly large benefit margin and can thus absorb risk directly; when working on the open source codebase, the risk adjusted cost of development will be higher, perhaps $15,000,-. Add $5,000,- in solicitation costs, and you're up to $20,000,- - still a lot less than the benefit marigin, but it needs a lot of contributors to get going.
[1] Development projects will usually include both strategic changes (those changes done to get revenue from customers by sales) and tactial changes (changes done to support the strategic changes, but without direct value in and of themselves.) Giving tactical changes back to the open source project one is branched off makes commercial sense; it decreases merge costs when updating from the free codebase, and increase employee happiness.
[2] Yes, I know about the Free Software Bazar, (no offers since august; no offers claimed since september 1999), SourceXchange (does not do pooling; seems to work for company-sponsored offers) and CoSource (does pooling; has transcated a total of $17252 since august 1999, with $9678 going to a single project. This is about two months of paid developer time at consultancy rates, total.)
How does this benefit MS?
MS has a number of codebases they are effectively guaranteed revenue from. Their market share is larger than the competitors in most areas. They've already sunk the development costs incurred so far. With GPLed software driving prices for alternatives towards zero, it gets harder for proprietary competitors to make a profit, and MS can stand the price war WRT development quite a bit longer than them (due to having a large number of copies to spread the development costs on.)
This is likely to effectively squeeze competitors out of the market, until you get to a point where you're only left with two forces: Open Source alternatives and MS. If the Open Source alternative is GPLed, MS can raise the prise almost as far as they want for those that don't get the features they need from the Open Source codebase - creating a new proprietary competitor will be too expensive.
I'm not certain this is going to happen, but the possibility is distinctly there.
Eivind (in most cases in favour of the BSD license, if that wasn't clear;)
I did spot checks on 4 different domains; none of them were in the least way blockable (promotional sites for various normal products.)
I'll agree that a-celebrity.com is in the lingerie category and that this is an error from Peacefire; however, I think sniping on Slashdot after checking one data point just isn't good enough. I won't even talk about the voteups...
Oh, and you ALSO have to reinstall your box if somebody out on the net mail you telling you there is a security issue on some software you are running which is remotely exploitable.
To reinstall or not is a tradeoff. The distinction between being told about a security hole by somebody you don't know hasn't exploited it and being told about a security hole by somebody that has exploited it and tell you they hasn't done any "bad stuff" is fairly artificial.
'Reinstall after breakin' is a rule of thumb, mostly intended to communicate that it is close to impossible to secure a box against somebody that has had control of it.
The BSDs do not do this because it is fairly pointless unless you have a fast one way hash function. If you use MD5 or SHA-1 to construct a MAC (Message Authentication Code) for use as a SYN cookie, you will usually be more vulnerable than without the SYN cookies, due to the increased CPU usage.
I worked some on designing alternate MAC schemes for use for SYN cookies in *BSD a couple of years ago, but never came up with anything worthwhile.
This is not correct. I live in Norway; we have one of the largest wireless adoption rates in the world (last year, there were sold half as many handsets as there are people); getting a landline usually goes plenty fast (a day or two if you insist on getting it quickly.)
Cellular adoption rates are large because getting cellulars is easy. I can walk into a random gas-station, pay less than $50, and walk out again with a working phone (depending on the gas-station - if they are connected to the 'bad' cellular network, I might have to wait until the next business day for the phone to be activated.)
Patenting something means you have to disclose the information (unless it is classified due to national security.)
This means it is easily available to everybody that cares to look, not "driven underground." Patents were designed to force publication, so the technology would be easily available once the patent expired. Implementations of said technology will be driven underground, of course.
Because Unix != Unix, as you should be well aware of. The Slashdot servers are AFAIK running Linux; what was installed in front of them was FreeBSD. FreeBSD has a number of features that make it better at handling attacks (dummynet, *_BANDLIM, etc) that I do not believe have equivalents for Linux. There are also some aspects of the basic kernel networking architecture in FreeBSD that might increase attack resistancy (but I suspect they do not make much difference for that case).
It might be possible to switch the main servers from Linux to FreeBSD, but as an interrim solution I think putting a FreeBSD firewall in front of them was a good tradeoff, giving time to evaluate whether an OS change on the servers themselves are warranted, or if there are reasons why keeping Linux make more sense.
Copyright does not apply to interfaces, according to US precedence. Thus, if you turn a GPLed program into a library, the library will be a derived work, but the interface will not be covered by copyright, so any program can use that interface, and not be covered by the GPL (as the GPL covers a set of copyrighted materials - see section 0 - and an interface is not covered by copyright.)
The library will be covered by the GPL, but this does not matter, as the GPL only covers copying, distribution, and modification.
If you are using a dynamic link library, and you are not including code from the original GPLed program (e.g, through macros or inline functions), linking will usually be done only locally.
Thus, there is a loophole in the GPL that as far as I can tell can't be closed - and I think the Open Source community will be damn glad of this in the future, as it will allow easier abandoning of the GPL, and thus makes it possible to get rid of its damaging effects faster.
The kiddies do DoS attacks against IRC servers to reach particular goals.
There are, in my experience, three common goals the kiddies go for:
Getting operator status (AKA op/chanop) on a particular channel, either in order to "fix" it (for a channel that has lost op or has other problems), or in order to do a takeover (where there are legitimate operators in the channel, and the kiddie want to take control of the channel in order to brag or similar.)
Attacking / annoying a particular server operator (AKA IRCop/oper), usually as revenge for the oper "slighting" the kiddie somehow, e.g by doing something about a previous takeover by the kiddie.
To try to pressure a server into giving them IRCop status (not that I've heard of it every working, but I still know of kiddies that regularly try this ploy.)
The kiddies are usually NOT out to DoS down the entire IRC network; they are using that network, and trying to gain prestige with other kiddies on it. Their attacks are fairly precise, and usually fairly short.
As a server operator, I think that the idea of shutting down the IRC network to send a message to the kiddies is a good idea. I have a couple of concerns with it, though:
It remove the service from the legitimate users during that period.
It is not coordinated across networks; AFAIK, the main bulk of kiddies play on efnet, not IRCnet. In order to send a proper message, efnet should have been closed, too, and I know it isn't - there hasn't even gone out a request to the european oper list (I've not checked the US list.)
It is pre-announced, which means that the kiddies will arrange for alternate communications means (e.g, by using efnet) during the shutdown.
However, all in all I still think it is a rather good way of saying Enough already!
I don't hate the BSD license, I just think that the GPL is better for everyone as a whole, rather then the individual. I really don't understand why your so upset about this, it's not taking food out of your mouth? Can you explain why GPL code can hurt you?
Taking the long view: The GPL creates a total fork between proprietary software and free software. By blocking proprietary derivates, you create a baseline where a certain level of functionality (the level of the GPLed program) is required to be free. Let's call this level N.
A user wanting to get functionality level N+1 and not caring about whether they use proprietary software or not will have to pay for N+1. If only a minority segment are willing to pay the accumulated cost of N+1, they may not be able to get N+1 because there isn't enough of them to pay for the relevant risk for developing N+1. If there were no forced free alternative, all users would pay for N+1, and this might push the cost down far enough that it overall low enough to not matter (development cost divided by a large number of users is low; development cost divided by a small number of users is high.)
This blocks the developer that could be involved in developing N+1 part if there were no free (as in free beer) "competition". It also blocks the developer that could be involved in developing the +1 part if there was a free (as in freedom to keep his changes) source base to base off.
And all of this for no gain for open source, because the developer of +1 will have two parts of the +1: Strategic and tactical changes. The strategic changes are the changes the developer actually gets revenue from; the changes that add value to the user. The tactical changes are changes that are just needed to get the strategic changes in place and out to the users. These, the smart developer would give back to the comunity, as this gives him the following benefits:
Decreased merge costs. Have you ever tried to merge between divergent sourcebases? Merging is expensive. And if the developer do not merge, the open source product will (assuming it is being actively developed) move past the proprietary derivate - and the users will go open source.
Goodwill in the open source community. I have given code back before (now defunct properitary derivate of FreeBSD, used in an embedded system); this do give benefits - other developers are willing to help you solve your problems. I've had the best engineers of one of our competitors trying to help out in getting things to work, and have helped them in return - because all of us were interested in getting the main sourcebase to work as well as it could.
Goodwill among the employees. Who do a company that want to do proprietary derivates of a free software system employ? Us. Yeah, that's right, the open source developers. Guess how happy we would be if changes that could be given back with no ill effects were kept proprietary, and we had to spend our days merging these back in.
Increased popularity for the open source codebase. From a company perspective, you can read this as "Increased amount of development we do not have to pay for, but which do give us an edge compared to companies working from other codebases."
So, a smart developer will give back, and thus both the developer and the open source community will be enriched. And really: Are we scared of stupid proprietary developers?
Eivind.
P.S. We have ended up giving back >90% of the changes we did - the remaining being tweaks that have no value to the overall community, but would allow a direct competitor doing a clone (and nothing but a clone) of our product to get a faster or better result. We did not know beforehand how much of our changes would end up in which category - so without the ability to keep changes proprietary those 90% would never have happened.
In order to get this going for an initially small open source project, you'd need an ad broker that is willing to sell in a small website - probably one that would be willing to put up with sites doing network ads only.
Slashdot Mirror
As for signatures: Yes, you need one signature per combination of recipient and message - I tried to communicate that in the protocol description (by describing the recipient address as part of the message), but it obviously didn't work out communication-wise :-(
Eivind.
Enforcing "charge per e-mail" and enforcing "you cannot spam" is not technologically the same at all.
Charging for e-mail can be implemented with digital cash, A trivial scheme for this is as follows (for Alice sending an e-mail to Bob, with Trent acting as a trusted third party. In practice, each of these would be done by a computer, and you'd want a more complex scheme that allows Bob to finally get the money instead of Trent):
Now, if Mallory (a spammer) want to send a mail, she has to pay Trent. Unless she pays Trent, she won't get his signature, and Bob won't accept her mail.
Thus, the problem of trusting "all the people on the Internet" reduces to trusting the people that are supposed to take payment before signing - and these should be way fewer than the number of people on the Internet.
The above scheme also keeps privacy for the mail sent - the only potential lack of anonymity is for the sender, who needs to pay Trent somehow. This is, however, a separate issue.
Enforcing the rule "You may not spam" is a totally separate issue. It can't be done without checking whether the e-mail in question is spam. This means either:
Neither of these seem particularly realistic.
Note that the payment system described was designed to be as simple as possible. It was just made to put down the argument in the parent. If I was to design a system for actual use, I would do a protocol that led to Bob getting the money in the end (instead of Trent), among other things. I'm fairly certain this this is possible, but it definately require more complexity than I wanted in the example.[1]
Eivind.
[1] The problem is keeping Bob anonymous while not having any post-receive enforcement possibilities against Alice. If it is OK to identify to Trent that Bob has gotten an e-mail without identifying that it is from Alice, this can be done by having Trent do a blind signature on a checksum + Bob's key, and then have Alice unblind it and let Bob present the signed packet to Trent for collection. If post-fact enforcement against Alice was possible, we could use traditional offline Digital Cash schemes.
For a better analysis of optimization in this specific part of the sort space, I recommend Jon Bentley's classic "Engineering a sort function".
This paper discuss how to implement an optimal sort, after having done real-life measurements. Conclusions include dropping to an O(N^2) sort algorithm when qsort partitions become small enough - insertion sort was choosen. (The selected cut off was secven elements at that point; it may be that it would be sensible to choose a higher cutoff for the generic case now, as the cache locality might help. However, I won't bet on this either way without doing measurements.)
The qsort implemented there is the one still used in at least FreeBSD. I don't know the status for other OSen.
As for big O notation: The discussion in the previous post is so imprecise as to be misleading. It use "cost" and "complexity" where it discuss asymptotic complexity; these are distinctly different, and it is necessary to be quite clear on the distinctions to do correct analyses.
Big-O notation measure asymptotic complexity over an arbitrarily selected set of basic operations assumed to have unit cost. It discard all constants to make the analysis easy to do and easy to work with. This is a useful tool, but it only measure asymptotic complexity, and it only does it based on arbitrary basic operations.
In practice, a mere factor 1000 speed difference (one second to twenty minutes) might be quite noticable. This will be REMOVED from the big-O analysis, which can make it point in a quite different direction from the truth.
In the parent post, sorting 1000 elements is assigned a unit cost, claiming that the time will be similar for a bubble sort and a quick sort, and "low enough not to matter". Further, the conclusion is "never use bubble sort". Assuming a naive implementation of both bubble sort and quick sort, and a set of arrays that is already sorted, the quicksort will be O(N^2) and the bubble sort will be O(N) in the number of items in each bin. This is a quite noticable difference in asymptotic complexity.
A naive programmer is in my opinion the only relevant assumption if we're to give absolute advice on simple sort functions. A non-naive programmer will know how to do complexity evaluation, will know the tradeoffs on startup of the various algorithms, and will only be implementing a sort him- or herself because actual speed measurements or specific knowledge of the sort behaviour show that the system supplied sort is not fast enough for the case in question, and that a custom sort can do better. (S)he will also evaluate whether the data to sort is likely to be almost sorted or highly random, and thus which kind of algorithm is likely to go faster. (And insertion sort/bubble sort is actually faster also for large data sets if they're almost sorted beforehand.)
Eivind, who if he had to give general advice would give "evaluate qsort, mergesort, heapsort, insertion sort, and using a data structure that keeps order before choosing bubble sort."
Why am I "married" to command line editors? There are really two reasons: Flexibility of context for use, availability in the context I am, and the price of screen real estate.
I'll address these in opposite order (which I think may be in reverse of priorities, but I'm not sure):
A plain xterm with a minimal border takes less screen real estate than a GUI editor. Screen real estate is a limited commodity - I'll do more or less anything to get more space for what I'm actually working on instead of decorations. And what I'm working on is the text I'm editing, not the buttons and menus that sit there.
A "command-line-based editor" (started from command line and run in the same window allows me to edit a file *in the same visual context as I already was*. This means that I have less of context change than if I either start a new window or use an editor launcher to get a buffer in an already running editor.
And finally, a terminal-based editor gives me flexibility to use the same editor in most contexts I use an editor. I can run it in a console to fix up a config file on a machine that hasn't got X yet, I can run it remotely on a server that isn't supposed to have X installed, I can run it on a remote machine I don't trust to have an X connection to my box (as an X connections allows keyboard snooping), I can run it when I sit on a Windows box with no X and should fix an issue with a server for a customer that use Windows desktops and Unix servers, I can run it when there is enough latency for X to be a pain, I can run it against servers where an X based editor takes too much resources (yes, these exists - for instance, I'd feel bad about running an X based editor on the FreeBSD.org servers, for resource reasons), etc, etc, etc.
Basically, there are a couple of direct UI advantages to terminal based editors compared to X based editors, as well as there being a lot of times it just isn't feasible to run an X editor. Until an X editor in itself is noticably better than the terminal based editors (and that day may come, but I don't know of any X based editor that is clearly better) people like me will keep running only terminal based editors, instead of running an X based editor with a side-dish of a *different* terminal-based editor whenever we can't run the X-based one.
Eivind.
That's not necessary - it's a question of where you aquire your new friends. I've been getting female friends continually (and I'm 29 now).
However, at the moment I'm specifically trying to avoid female friends I don't sleep with, as I'm working on up'ing pickup skills. When I'm with female friends, I get positive feedback on behaviour that results in getting female friends - which is NOT the same as the behaviour that result in getting lovers.
Eivind.
In a way. The question is "What is good enough?" and "Solves what problems how well?". For me, the design problems in a lot of commonly used software (MySQL, perl, the pre 2.6 Linux VM, autoconf, the FreeBSD mergemaster tool, the Windows registry, the language SQL, ...) have bitten me, and in some cases keep biting me on a daily and weekly basis.
Of course, each of these have strengths that have made them be major players in their niche in the first place. This include
Note that I do explictly NOT list being a more efficient or better system overall. People are generally reluctant to take any larger investment of time than they have to, even if that increase overall productivity. The gains have to be perceived as large and fairly immediate before taking the time investment.
So - in my evaluation, "poor design" is important. It gives continious costs *and those costs tend to emotionally bind the users to the product with the flaws*. However, poor or good design is not important to whether a system gets adopted or not. , if it isn't so horribly bad that this is immediately obvious.
And to get back on topic: With MySQL, what I really hate is that it make up data in order to make sure inserts pass. This has made much more trouble for me than any of the other issues - the other issues are easy (though a lot of work) to work around and keep in mind, but accepting bad data requires a ton of verification at the DB-interface layer of the application - and this is non-obvious, and have not been implemented in a lot of code I have had to work with :-(
Eivind.
Eivind.
(I'm assuming you mean "IPF" as in IPFilter) Well, it is in a sort of twilight zone. The original license can be read either way, and the way most people have read it has been different from what Darren intended with it. And this is the reason why IPFilter has been allowed into the base (along with Darren not saying anything about it, while he should be perfectly aware of the *BSD license policies, as he has a commit bit in both FreeBSD and NetBSD.)
We are looking at how to resolve it, with either Darren changing the license terms or IPFilter being delegated to a port.
Eivind.
Unless the netfilter developers make sure to contact all relevant contributors and get an OK for distributing under alternative licensing (ie, BSD style licensing), at least FreeBSD will stick with ipfw (which, contrary to the LWN article, is the primary firewall used in FreeBSD.)
Eivind, FreeBSD developer, speaking his own opinions.
Get your head out of the sand, please.
I believe, as the poster you replied to, that this isn't corporate policy. Not because MS says so (MS has close to zero credibility in my eyes), but because the backdoor was so stupidly executed. MS has a lot of good engineers - if this had been an official policy, it would have been nicely executed, and if uncovered would look just another random security hole. It would probably even be harder (but more reliable) to exploit than the non-intentional ones!
Eivind.
This shows lack of comprehension. I used to (and still do) read similar texts because I enjoyed it, from about 3rd grade and onwards. If I was somewhere I needed to kill time, I usually tried (and try) to bring some technical/academic text (computers, science, business, ...) and some fiction - as what I want to read depend on my mood. However, all of it is for my own enjoyment, not to show off.
As to not showing interest in what other people are interested in: As a teenager, you are by necessity overfocused on your interests - because you have not yet got the background necessary to handle a spread of interests. There just hasn't been enough time to learn that many sides of how the world works to a sufficient level of detail (at least not with the amount of focus most of us are able to produce.)
Eivind.
How did they the uneducated public "really screw things up?" They invested in things that looked promising (the internet,) and got burned when the profit models were exposed as bad ideas (by the lack of profits.) So what got screwed up? The markets continue to buy and sell stock.
By pushing the stock market up to an immense bubble due to overinvesting in tech stock, similar to what was done with railroads in the mid-1800s, radio in the 1920s (remember the bust of october 29th 1929?), and various other tech waves at other points. There's presently a few trillions of dollars too much in the public stock market compared to discounted future earnings; if any of the old patterns hold, these will need to go over time - and will possibly go as a very sharp drop.
Presently the value of the US stock market is larger than the GDP - while historical data shows it as always regressing towards a value of 50% of the GDP, with large swings on each side.
Eivind.
Nice attempt at emotional manipulation.
I'm probably in one of those families you consider to have been "torn apart by drugs." My stepbrother was an addict for over half a decade. However, as far as I can tell, the problems we've had with him has been due to drugs being illegal. He's been pulled into a scene of criminals, have been chasing after fast money, and have been drugged out of his mind - as a feedback loop from the stress of that scene.
With drugs legal, he might still have taken them, and still have taken them to excess - but he would have done it without trying to earn money off drug deals, without having people after him to crush his kneecaps because he owed them money, without threaths to his family - and would be likely to have had a much better chance of being eased back into society, instead of having to almost die from it before ending up in a rehabilitation program.
As an interesting case in point, suicides in the Netherlands is the lowest in Europe - considered to be due to people that are desperate smoking themselves out of the world for a period, instead of dying.
And aspirin kills more people annually than cocaine, while alcohol-related deaths in the US is at 10 times the number of deaths related to illegal drugs (approx 150,000 vs 15,000 if you use the same way of counting - I just looked it up.)
Yes, the drugs that are presently illegal often waste parts of people's lives. By keeping them illegal, they waste larger parts of the lives, and in more extreme ways - for a possible reduction in the number of people that try them. Useful, isn't it?
Eivind.
For every small company that can't make money writing GPL software, there are 500 that can make money by using it. It saves a lot of money at my work that I can use perl for my scripting, apache for my webserver, and php for additional web stuff.
Perl is under the artistic license, lately dual licensed with the GPL. Apache is under an extended BSD license. PHP is under an extended BSD license. 0.5 out of 3 isn't so bad (though the available artistic licensing of perl makes the GPL fairly irrelevant.)
I can get these items at no cost and I don't have to worry about them ever disappearing off the face of the earth, while MS can do what they please. So tell me again how this benefits MS and how this is killing companies?
I'm going to take these in opposite orders:
How does the availability of free, copylefted software kill companies?
There are two sides to this, both of which are results of economic changes. The first is that some types of software becomes available at close to zero cost along with the benefit of the ability do easy codechanges, outcompeting higher priced proprietary software. This is good; the workforce and capital of the companies are redirected to other places where they can contribute more to society.
Then there is the second, dark side: Copylefted software block economic models which give groups of end-users choice and tweaking for their needs. In a proprietary environment, a development company can do changes to source code as an investment, based on how many more people they expect to be buying the software based on the changes they do. For a copylefted product, the changes needs to be paid for by the first comer(s).
This is easier to see in a scenario description. There are two cases here: Market dominated by proprietary or BSDLed software, and market dominated by GPLed software. BSDLed/proprietary are fairly equal for this scenario; either the company has the maintained codebase available for proprietary use because it is being maintained due to market income, or it has the codebase it can use available due to open source maintenance. (Codebases can also be available with royalties due to commercial licensing; this gives similar cases with more complications.)
Let's set the cost of developing the codebase in the first place at $500,000,-. Let's further say that a particular new feature has a value of $100 for 1000 users, and that the cost of developing the feature is $10,000,-.
In a proprietary or BSDLed environment, this means that the company can develop the feature and sell it for anywhere below $100,000,-, while still both giving value to each customer. $90,000,- is available as cost/benefit difference, and up to this amount can be taken out as profit by the comapny while still adding value to society. This is enough available profit that it is reasonable to take the intial risk. Thus, the customers get their feature and the company get profit and everybody is better off (likely also the open source codebase, due to the distiction between strategic and tactical changes[1].)
Now for the GPLed case. There isn't a codebase available for the company to do properiary changes to, ao it has to develop that before going on to the profit side. Whoops, there was a $500,000,- cut of their $90,000,- potential profit - that's a $410,000,- loss. No way they are going to give those users the feature.
Well, what about the users themselves? Can't they just pay for the change to be incorporated into the GPLed codebase?
For each individual user, this is a loss. Paying directly to have the feature incorporated is a 100x cost increase compared to the benefit gotten back - not interesting.
Paying as a group is theoretically possible, but fraught with problems[2]. First, you need to get hold of the people in the group and get them to agree about what they need, and agree to pay for something they haven't seen, and which they will get no matter if *they as single entities* pay or not. Second, the cost of development will likely be higher. The developer in the proprietary example gets his profit from a fairly large benefit margin and can thus absorb risk directly; when working on the open source codebase, the risk adjusted cost of development will be higher, perhaps $15,000,-. Add $5,000,- in solicitation costs, and you're up to $20,000,- - still a lot less than the benefit marigin, but it needs a lot of contributors to get going.
[1] Development projects will usually include both strategic changes (those changes done to get revenue from customers by sales) and tactial changes (changes done to support the strategic changes, but without direct value in and of themselves.) Giving tactical changes back to the open source project one is branched off makes commercial sense; it decreases merge costs when updating from the free codebase, and increase employee happiness.
[2] Yes, I know about the Free Software Bazar, (no offers since august; no offers claimed since september 1999), SourceXchange (does not do pooling; seems to work for company-sponsored offers) and CoSource (does pooling; has transcated a total of $17252 since august 1999, with $9678 going to a single project. This is about two months of paid developer time at consultancy rates, total.)
How does this benefit MS?
MS has a number of codebases they are effectively guaranteed revenue from. Their market share is larger than the competitors in most areas. They've already sunk the development costs incurred so far. With GPLed software driving prices for alternatives towards zero, it gets harder for proprietary competitors to make a profit, and MS can stand the price war WRT development quite a bit longer than them (due to having a large number of copies to spread the development costs on.)
This is likely to effectively squeeze competitors out of the market, until you get to a point where you're only left with two forces: Open Source alternatives and MS. If the Open Source alternative is GPLed, MS can raise the prise almost as far as they want for those that don't get the features they need from the Open Source codebase - creating a new proprietary competitor will be too expensive.
I'm not certain this is going to happen, but the possibility is distinctly there.
Eivind (in most cases in favour of the BSD license, if that wasn't clear ;)
I'll agree that a-celebrity.com is in the lingerie category and that this is an error from Peacefire; however, I think sniping on Slashdot after checking one data point just isn't good enough. I won't even talk about the voteups...
Eivind.
To reinstall or not is a tradeoff. The distinction between being told about a security hole by somebody you don't know hasn't exploited it and being told about a security hole by somebody that has exploited it and tell you they hasn't done any "bad stuff" is fairly artificial.
'Reinstall after breakin' is a rule of thumb, mostly intended to communicate that it is close to impossible to secure a box against somebody that has had control of it.
Eivind.
I worked some on designing alternate MAC schemes for use for SYN cookies in *BSD a couple of years ago, but never came up with anything worthwhile.
Eivind.
Cellular adoption rates are large because getting cellulars is easy. I can walk into a random gas-station, pay less than $50, and walk out again with a working phone (depending on the gas-station - if they are connected to the 'bad' cellular network, I might have to wait until the next business day for the phone to be activated.)
Eivind.
This means it is easily available to everybody that cares to look, not "driven underground." Patents were designed to force publication, so the technology would be easily available once the patent expired. Implementations of said technology will be driven underground, of course.
Eivind.
It might be possible to switch the main servers from Linux to FreeBSD, but as an interrim solution I think putting a FreeBSD firewall in front of them was a good tradeoff, giving time to evaluate whether an OS change on the servers themselves are warranted, or if there are reasons why keeping Linux make more sense.
Eivind.
Copyright does not apply to interfaces, according to US precedence. Thus, if you turn a GPLed program into a library, the library will be a derived work, but the interface will not be covered by copyright, so any program can use that interface, and not be covered by the GPL (as the GPL covers a set of copyrighted materials - see section 0 - and an interface is not covered by copyright.)
The library will be covered by the GPL, but this does not matter, as the GPL only covers copying, distribution, and modification.
If you are using a dynamic link library, and you are not including code from the original GPLed program (e.g, through macros or inline functions), linking will usually be done only locally.
Thus, there is a loophole in the GPL that as far as I can tell can't be closed - and I think the Open Source community will be damn glad of this in the future, as it will allow easier abandoning of the GPL, and thus makes it possible to get rid of its damaging effects faster.
Eivind.
The kiddies do DoS attacks against IRC servers to reach particular goals.
There are, in my experience, three common goals the kiddies go for:
The kiddies are usually NOT out to DoS down the entire IRC network; they are using that network, and trying to gain prestige with other kiddies on it. Their attacks are fairly precise, and usually fairly short.
As a server operator, I think that the idea of shutting down the IRC network to send a message to the kiddies is a good idea. I have a couple of concerns with it, though:
However, all in all I still think it is a rather good way of saying Enough already!
Eivind.
Taking the long view: The GPL creates a total fork between proprietary software and free software. By blocking proprietary derivates, you create a baseline where a certain level of functionality (the level of the GPLed program) is required to be free. Let's call this level N.
A user wanting to get functionality level N+1 and not caring about whether they use proprietary software or not will have to pay for N+1. If only a minority segment are willing to pay the accumulated cost of N+1, they may not be able to get N+1 because there isn't enough of them to pay for the relevant risk for developing N+1. If there were no forced free alternative, all users would pay for N+1, and this might push the cost down far enough that it overall low enough to not matter (development cost divided by a large number of users is low; development cost divided by a small number of users is high.)
This blocks the developer that could be involved in developing N+1 part if there were no free (as in free beer) "competition". It also blocks the developer that could be involved in developing the +1 part if there was a free (as in freedom to keep his changes) source base to base off.
And all of this for no gain for open source, because the developer of +1 will have two parts of the +1: Strategic and tactical changes. The strategic changes are the changes the developer actually gets revenue from; the changes that add value to the user. The tactical changes are changes that are just needed to get the strategic changes in place and out to the users. These, the smart developer would give back to the comunity, as this gives him the following benefits:
Have you ever tried to merge between divergent sourcebases? Merging is expensive. And if the developer do not merge, the open source product will (assuming it is being actively developed) move past the proprietary derivate - and the users will go open source.
I have given code back before (now defunct properitary derivate of FreeBSD, used in an embedded system); this do give benefits - other developers are willing to help you solve your problems. I've had the best engineers of one of our competitors trying to help out in getting things to work, and have helped them in return - because all of us were interested in getting the main sourcebase to work as well as it could.
Who do a company that want to do proprietary derivates of a free software system employ? Us. Yeah, that's right, the open source developers. Guess how happy we would be if changes that could be given back with no ill effects were kept proprietary, and we had to spend our days merging these back in.
From a company perspective, you can read this as "Increased amount of development we do not have to pay for, but which do give us an edge compared to companies working from other codebases."
So, a smart developer will give back, and thus both the developer and the open source community will be enriched. And really: Are we scared of stupid proprietary developers?
Eivind.
P.S. We have ended up giving back >90% of the changes we did - the remaining being tweaks that have no value to the overall community, but would allow a direct competitor doing a clone (and nothing but a clone) of our product to get a faster or better result. We did not know beforehand how much of our changes would end up in which category - so without the ability to keep changes proprietary those 90% would never have happened.
- TeknoSurf.com (has moved to www.advertising.com - you'll get a redirect)
- A mix of pay per clickthrough and pay per banner, with mainly pay per click
- Minimum 1000 impressions per month
- ValueClick
- Pay per click only
- Minimum 15000 impressions per month
- CyberBounty
- Seems to be pay per user that accept free stuff from sponsors through them, or buy stuff from sponsors (mostly the former)
- Minimum 350 unique visitors per day
as some he's had good experience with for this type of use.Eivind.
Does anybody know of such a broker?
Eivind.