Slashdot Mirror

A
  B
  C
  Techne

I find it very improbable Apple will sue. I think they'll ignore it.

You deserve to be mod'ed up. When a similar project passed some milestones on NetBSD, there was not even a cease and desist letter which would certainly have been seen as acknowledgement

There was a similar attemptin NetBSD almost 10 years ago. .

That prehistoric project implemented Mach-O loader, Mach system calls, and has been able to start OS X display server. It felt short actually displaying something useful, and died from lack of user interest.

The blobs he is referring to and that linux-libre removes are generally firmware and microcode that are uploaded to devices on boot. Yes, some devices don't work without it. Some devices work partially. But I would definitely not say it is "a lot, lot less functional".

If I'm not mistaken, Debian already removes these blobs from their kernel package, but they can be installed with a separate package.

Hell, even OpenBSD (who are perhaps the most zealous of the BSDs) accepts firmware blobs, as long as they come with a license that allows free redistribution.

The language of choice depends on the community. If everyone is using Mumps, you should use Mumps. http://en.wikipedia.org/wiki/MUMPS You want to be able to share your work with the rest of the community.

One application I am aware of where Python is widely used is bioinformatics.
http://onlamp.com/pub/a/python/2002/10/17/biopython.html

Having said the above, Python has a lot to recommend it. It has become the initial teaching language of choice. There will be some people whose only language is Python. That's OK. It scales and can be used within almost any programming paradigm. If your only language is Python and you don't have much data to process, why would you bother learning something like R. http://en.wikipedia.org/wiki/R_(programming_language)

Why not opt for OpenBSD instead, there are many sources that put it as the most secure operating system.

"It's why programming is a form of art. It's where you get to express your creative vision in a concrete fashion."

No actually, it's an engineering discipline, that's probably why you're getting it so very wrong. People want solid, well structured applications, not arty farty bullshit.

http://www.burlingtontelecom.net/~ashawley/gnu/emacs/ConText-Kelty.pdf Page 2 ... nice reference to "Donald Knuth's monumental work The Art of Computer Programming [Knuth, 1997])" ... I'll take Knuth's opinion over yours any day, and I'm not the only one http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming

American Scientist has included this work among "100 or so Books that shaped a Century of Science", referring to the 20th century,[2] and within the computer science community it is regarded as the first and still the best comprehensive treatment of its subject. Covers of the third edition of Volume 1 quote Bill Gates as saying, "If you think you're a really good programmer . . . read (Knuth's) Art of Computer Programming . . . You should definitely send me a résumé if you can read the whole thing." [nb 2] The New York Times referred to it as "the profession's defining treatise".[3]

Others:

The Art of Unix Programming: http://www.catb.org/esr/writings/taoup/html/

Or this: http://onlamp.com/pub/a/onlamp/2005/06/30/artofprog.html

Einstein:

After a certain level of technological skill is achieved, science and art tend to coalesce in aesthetic plasticity and form. The greater scientists are artists as well.

Quotes from RMS, Brookes, etc. Programming is art when done right. You obviously are incapable of seeing that by your own words - must be the brain-damage from too much Java, if you have to write stupidity like this:

just get the fuck out of the industry, there is no place in it for you. If you want to do art then fuck off to hipster land and go do it, the software development industry is not the place, we don't want your poorly architected, insecure, poorly tested code polluting the world's computers based on the justification you were "being creative and expressing yourself" - with a fucking buffer overflow on a public internet facing system.

I'm the one who got called in to rewrite the server at one company when nobody else could complete the project (note - this is a server, not just an application) - it spawns 400 threads at startup, each one waiting for work, does the task, then goes back into the pool. It responds to 1,000 requests per second, without ever having a memory leak or killing and re-spawning a thread to retrieve memory. It's not impossible to write leak-proof c and c++ code, but it is an art, one you will never be able to achieve, because you are no artist.

-- Barbie

Regardless of a developers motivation, the only practical effect is accurately characterized.

In that case, it's the same effect of the GPL as well.

companies, given the choice, will always retain their IP

Many companies contribute code to BSD-licensed projects, and even more fund them to continue their work. In short, you're utterly wrong about the practical effect.

IBM widely publicised their billion dollar investment in Linux in 2001 alone ( http://news.cnet.com/2100-1001-249750.html ) Oracle has their own distro, and is funding btrfs. HP has made installating their printers under linux easier than on windows. The biggest contributors to linux kernel in order are: individuals 18%, Red Hat 12%, Intel with 8%, IBM and Novell with 6% each, and Oracle 3%. The scale of corporate contribution to Linux is many orders of magnitude than anything in the BSD world. (http://apcmag.com/linux-now-75-corporate.htm)

BSD's aren't unified because the license sets up incentives for forking and keeping changes proprietary.

The various BSDs are all BSD licensed, yet they remain non-unified. Repeating your blanket assertion won't make it any more true the second time around.

If you're not going to attempt to reconcile reality with your assertions, everyone should ignore all assertions you make.

see above for evidence of the greater size of corporate contributions to GPL kernel vs. BSD system. Now you argue that any disparity of any kind results from network effect. I will point out that Linux has no shortage of court cases in it's history. have a look at sf.net where the overwhelming majority of projects use GPL or LGPL. The top ten downloads from sf.net? 8 GPL, 1 LGPL, 1 a mix (portable apps.)

http://sourceforge.net/top/toplist.php?type=downloads_week

As for the effect of LSB, for example it specified the standard packaging format to be .rpm... ever used debian, ubuntu, arch, or gentoo?

Yes, though it's no their preferred format, they ALL include utilities for handling RPMs.

It's the native format and normal idioms that we are talking about here. By your logic, BSD is linux because you can install RPM's on it: http://onlamp.com/pub/a/bsd/2006/01/12/Big_Scary_Daemons.html?page=1

He gives you exactly the same freedoms he has.

Nonsense. He can go back and re-license all of his stuff at any time. The GPL is not binding to him. He binds everyone else with it. Sure, with the GPL, you're giving up your freedom in exchange for someone else's code. It may be a reasonable trade, but it's NOT freedom.

The problem with your analysis, is that it assumes a single copyright holder. The proper way to use GPL, as is done in the linux kernel, is for all contributors to retain copyright on their contributions. In that scenario, as soon as the original author changes the license, he has to revert his code to the state it was before he accepted any contributions... So he is in the same position as anyone else. Anyone can take their marbles (and no one else's) and go home.

The security comes from the fact that in any GPL project that becomes sufficiently important, there will be distributed copyright holders, and it becomes impossible to make it non-free. That is why everyone, including the original author, has the same freedom. They can only withdraw with what they themselves have contributed.

Your assertion that Linux is more popular BECAUSE IT IS GPL'ed is utterly laughable. Any number of very liberally-licensed s

To advantage which of it own Apps does Apple use its OS advantage ?

On the iPad, only Apple software can multitask (this article has a list: email client, SMS text client, and other apps). On any of their platforms, only Apple software may use the APIs that let you customize the way the UI widgets display. Only Apple software can use the full functionality of the accelerometer. Here is a blog post discussing some undocumented OS X features that made Safari much faster than Firefox 3. And here is a blog post discussing how several apps were rejected for using undocumented functionality. And here is a whole article discussing undocumented Apple APIs, with examples of cool stuff that only Apple's own software is allowed to do. And here is an article discussing cool things that Safari can do, that Firefox isn't allowed to do. And here is a column that claims that Apple inserts undocumented APIs and uses them in its own code for years, without ever documenting them (but presumably without breaking them because it would break Apple's own code). Even the APIs for the WiFi are undocumented.

I understand the argument that Apple doesn't want to commit to supporting these APIs forever, like Microsoft has had to do with even obscure APIs in Windows. If you use these undocumented APIs to do cool things, and Apple revises the OS, your app may break. And Apple doesn't want the customer to think it's Apple's fault that your app broke.

But I also understand the argument that some of these APIs allow for really cool stuff, which is currently reserved only for Apple. People don't like this.

As for me, give me Linux anyway. No such thing as an "undocumented" API, and there is no entity that has an unfair advantage over everyone else, and I can install any software I want.

steveha

I would go further than just publishing the code used in scientific research. I would build the code by running it a real open source project. In fact, I've done exactly that, and it worked out incredibly well. I believe our open source approach lead to better science, and also better software.

I worked with researchers from MIT and Columbia on a research project that involved gathering and analyzing a large amount of publication data. The results of the study are about to be published (you can read the working paper at the lead researcher's website).

We intended the code for this project to be released from the beginning, so we ran it as an open source project. I followed the basic formula from Karl Fogel's excellent (and free to download) book, Producing Open Source Software: set up a website for the project, created lots of documentation, tried to make it as easy as possible for someone to get up and running, made the source available via Subversion, and made it easy to contact us.

Quality was really important for us, so we put a lot of effort into testing. I definitely believe that the fact that we intended the project to be open source from the beginning helped with that. We weren't treating the code as some piece of throwaway or replaceable lab equipment. I'm convinced that treating it as a real product of the research caused us to take the development and the quality much more seriously than a lot of researchers. I've since heard from other researchers who are starting to use the software as well, and everyone who sees it feels that it came out really well.

There was another scientific benefit that should definitely appeal to anyone who lives in the publish-or-perish world of science research. We published a paper specifically on the project (Azoulay P, Stellman A, Zivin JG. PublicationHarvester. An open-source software tool for science policy research. Research Policy 35 (2006) 970-974. -- there's a link to the PDF on the lead researcher's website.)

It's funny -- I wrote an article a few years ago with Jennifer Greene for O'Reilly ONLamp called What Corporate Projects Should Learn from Open Source. I'm now convinced that science research projects can also learn a great deal from open source as well.

I suppose that's a bit closer, but it still doesn't address the differences between fs defaults. ext4 is far more aggressive than ufs2 is by default. A closer comparison would have be to gjournal ufs and mount async which would have been a relatively close comparison to ext4, but that still would not be a fair io comparison as gjournal scales incredibly well but can double write time on single write. I am struggling to comprehend ext4 as a default filesystem in a server(or anywhere) however, considering it still has crash corruptions issues.

http://en.wikipedia.org/wiki/Ext4
http://onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=3

So in case any average consumer reads this, let's put an end to that myth. For instance, I'll compare the Starter Win7 disabled list in TFA with Puppy Linux:

• Aero Glass - well, Puppy has Compiz-Fusion.
• Personalization features - Yes.
• User switching - I couldn't find Puppy specifically, but most Linux can.
• Multi-monitor support - Yes, although spreading windows across more than one screen at once is iffier.
• DVD playback - probably; but might have to install VLC Media Player or something (which you can).
• Windows Media Center - well, not Windows, but definitely media.
• Remote Media Streaming - If Linux can, Puppy can with VLC. You can definitely stream from a Windows machine to Puppy.
• Domain support - Yes, with Puppy 4.1.
• XP Mode - well, no, but installing Wine may give compatibility similar to Windows 7! :P

If you want to know todays' O'Reilly, try http://www.onlamp.com/onlamp/port25/

Communication from the Open Source Community at Microsoft, ugh...

Company-Wide Instant Messaging with Jabberd by Oktay Altunergil

http://www.onlamp.com/pub/a/onlamp/2005/10/06/jabberd.html

wrong. quoting o'rly:

This recipe shows a system configured with both client and server certificates and keys. Many systems are configured as both clients and servers for STARTTLS because mail is often forwarded by one system to another. When the system receives inbound mail, it acts as a STARTTLS server. When it forwards that mail on to another system, it acts as a STARTTLS client. Therefore, the system needs to act as both a STARTTLS server and a STARTTLS client. Normally such a system uses the same certificate and key for both its client and server roles.

http://www.onlamp.com/pub/a/onlamp/excerpt/sendmailckbk_chap01/index1.html

Nope.

http://kerneltrap.org/node/6497
http://www.onlamp.com/pub/a/bsd/2006/04/27/openbsd-3_9.html
http://kerneltrap.org/blobs

BSD would have only become unencumbered by proprietary code had not the GNU project bugged them about it. read here: http://www.onlamp.com/pub/a/bsd/2000/03/24/bostic.html

First, a "you need to connect to the server every time you play" scheme is exactly what Steam does. I actually kind of like Steam. So long as Valve stays in business, all of the games on Steam (except Bioshock, of course) can be installed on as many machines as you like; you can suffer as many hard drive crashes as you want to, you can upgrade your machine as often as you want to. The only restriction is you can only play on one machine at a time, which isn't so unreasonable as all that.

I admit, when I bought Civ IV, I bought the retail box copy so that I could swap the disc between my machine and my wife's, so we could both play at the same time. I'm an evil pirate. :P The number of times we've actually done that is pretty low, though, as we're both busy professionals.

That aside, there are a few problems with this idea, although none of them are so dire that they can't be overcome.

First, putting some of your logic on the server means that customers on dialup, and customers with poor net connections are going to suffer from lag. Lag in a single player game is kind of unacceptable. Maybe you can pick logic that doesn't need to be updated "in realtime" (the price of arrows at the market in a game with a free market economy, for example).

Second, putting logic on the server means you need have the added expense of maintaining and running this server. If you ever decide to stop running the server, then no one can play your game anymore, and this is going to turn some people away from your game. The more complex the logic you want to move out of the game engine, obviously the more powerful and more expensive this cost is going to be.

Third, if you want to stop pirates, you have to move some substantial logic out of the game and onto the server (see the last point about expensive servers). Why? Because otherwise the pirates will just re-code the logic and add it back into your game, or else write an open source version of your server.

Here are a few things that have helped me out:

• The big one: go to LISA. It can be tough convincing the boss to send their one-and-only IT guy, but it's an incredibly exciting environment. You'll learn lots, you'll meet lots, and you'll get to rub shoulders with people doing incredible things -- and people in the same boat you are.
• If you can't go to LISA, start reading their proceedings. They've just opened up everything to the public (previously you had to wait a year if you weren't a member), and there are some incredible gems to be found. The MP3s from LISA '07 weren't as good as being there would have been (sob), but they're still damned good.
• You should still get a membership in SAGE. Subscribe to the mailing lists, get a subscription to ;login:, and inhale deeply.
• Look around for professional organizations to join, or other opportunities. There's a sysadmin group at the university where I work; there's also a committee trying to figure out what the university's IT strategy should be for the next 5-10 years. I've been lucky enough to be involved with both, and they're interesting. Sure, I run a small shop, but I've rubbed shoulders with (well, envied from across the room :-) the guy in charge of a cluster of computers that'll be processing data for the ATLAS experiment.
• Start your own techy/sysadmin conference, a la LUGRadio Live. No, LUGRadio Live isn't particularly sysadmin-oriented, but I have the strong impression that the organizers just decided they wanted to hold their own conference, and they did. And if you look at the schedule for their US conference, it's got a damned impressive list of presenters. (I'm considering starting a sysadmin conference next summer in Vancouver, BC...anyone interested?)
• Other sources of info: Planet Sysadmin (disclaimer: they've got my blog in there), ONLamp, and your local LUG.

Hope this helps!

Yeah. It's a nice article and there are a lot of improvements. Some unexpected like the better performance for SSDs.

Speaking of SSDs, I see CDs slowly but surely heading the way of the floppy. At some point, they're going to disappear from more or less all new units. They're off a few models already, but it's too soon to say when the tipping point will hit. When it does, the sales of read-only CDs will have to be replaced, possibly with read-write SD flash or USB sticks or something similar. Some thought will have to be put into how to best deal with that when the time comes.

A nice article regarding the new developments of 4.3

I wrote the pocket reference and also this best practices article for writing regular expressions. It's the habits I developed to avoid poking my own eyes out: http://www.onlamp.com/pub/a/onlamp/2003/08/21/regexp.html

VB remained relatively for 10+ years.

Not sure what your bones with Mono are though.

And on their website they state "Its [mono's] objective is to enable UNIX developers to build and deploy cross-platform .NET Applications." And "Our current focus is on inter-operating with the Microsoft SDK." Sure sounds like the goal is .Net compatibility to me.

>> Softupdates don't solve the important unclean shutdown fsck problem very well. Background fsck is a nightmare for any production system with non-trivial amount of spinning rust.

>How's that? I mean, I'd rather not have to fsck my terabyte RAIDs, but if I have to, at least the system can be running live and undegraded while the loose ends get cleaned up.

How is that? What do you mean how is that? It doesn't solve the unclean shutdown problem *very well*. Yes, it is better than nothing, but it is still not great. Undegraded is wrong, it consumes disk / controller / memory bandwidth and IOPS, and CPU time. This is often bad if you're running real workloads at the same time.

>> Wrong. Half the writes as compared to the naive gjournal journalling. Real modern journalling filesystems usually have the option to journal just metadata. What's more, journalling is far more flexible than softupdates. You can journal to a small battery backed RAM device for example.

> If you're just journaling metadata, then you're not getting the full benefit of journaling (and definitely not anything more than softupdates offers,

Yes you do, because you solve everything that softupdates does, and the unclean shutdown problem, and also have the option to far reduce the constraints on writeout if you use an NVRAM device for the journal.

Also, you really are getting the "full benefit of journalling" with metadata journalling. Or at least, a very large part of it. Checkpointing and crash recovery etc. have to still be done at the application level because UNIX's filesystem API is not transactional so it is often the case that the manipulations that are required span multiple filesystem calls anyway. So it isn't as if by using data journalling you can suddenly just do away with logging on your DBMS or anything like that.

> as it's basically an in-memory ordered journal of metadata transactions to be committed). As far as the battery-backed RAM: that's like saying cats are better than dogs because you can give them medicine if they get ringworm.

Now you're just confusing the issue because you've got nothing argue against it. Nice.

>> Wrong. There has to be some filesystem support work done.

>> Wrong. gjournal is a generic journaling provider. You can use it to wrap any other GEOM component. From it's own man page:

        "When gjournal is configured on top of gmirror or graid3 providers, it also keeps them in a consistent state, thus automatic synchronization on power failure or system crash may be disabled on those providers."

Presumably this is referring to journalling for the gmirror and graid3 metadata. Not filesystems.

> Pretty neat, huh? You can wrap it around your RAID to make it crashproof. If you think background fscks are bad, then you've probably never watched a few terabytes of mirror resync itself.

Mirror resync is bad sure, but it increases linearly with the size of the disk, and is generally easy
to turn into big sequential IOPs. fsck is a completely different beast for most contemporary filesystems.

> Anyway, what you misunderstood is that filesystems have to be altered to interact meaningfully with the underlying journal. UFS has been so modified. That doesn't mean that other filesystems won't work on top of it (which would be silly because a gjournal looks just like any other block device), but that they're not optimized for it.

I think you misunderstood.

From http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=3

You can use gjournal without any file system on top of it and with a really small *amount of work* you can use it with any file system FreeBSD has. Currently *only UFS support is implemented*.

So I think you are the one who overestimates your capacity for being right. Especially about things where you obviously know a little bit, but not really the full story.

All good points here, but please be care with the allusions you make towards the BSD world.
They are very serious projects.

There is a good interview with many key FreeBSD contributers about new technologies and improvements in 7.0. It is quite technical.

http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=1

Yeah, we always fall back on the government to help us out when us nerds aren't satisfied with how capitalism is driving the technological trends that need to happen.

But let's not forget those that went before us. Jun-ichiro Hagino, better known as Itojun, was one of the first researchers that was pushing for IPv6 since as long as I can remember (at least 2001). On top of that he was developing specifications for it and working through the BSD code to make it one of the first operating systems fully capable of being IPv6 compliant--starting a trend that needs to happen in more operating systems sooner. He even started documenting draft APIs to get developers thinking about how this would work inside software.

And then he died in a car accident at age 37. It's funny how you don't appreciate their work until they're dead. Almost like a painter or author.

Although many still carry on his work, the saddest part is that all his efforts to bring awareness to everyone about IPv6 may fall into the responsibilities of the government or, worse, capitalism.

We came to the conclusion that a foolproof alternative to strncpy() and strncat() was needed, primarily to simplify the job of the programmer, but also to make code auditing easier.

I'm just a bit tired of hearing people advocating it, when there's still close to nothing to show for it after 7 years of planning and some rudimentary prototyping.

That's nice.

I'm a lot tired of Internet blowhards thinking that they have all of the brilliant answers to the thorny software development problem of "Good, cheap, or fast -- pick two!" when we've already chosen "Good" and we've never not been able to pick "Cheap". I'm sure I don't have to tell you that Microsoft spent more money on paying the salaries of its Vista developers during their coffee breaks for one week than we've spent on Perl 6 in at least the past three years.

If you have a solution, please join one of the IRC channels or one of the mailing lists and enlighten us. "Code faster", "Stop trying," and "Release something that's not what you want to release nor meets your standards of quality or the reason you started this project," are unacceptable solutions. (See Can't You Just...? and Can't You Just...? redux.)

Close all the tabs except one, go to about:blank (or whatever firefox calls it).

Notice how the memory use doesnt go down?

These are pretty much textbook definitions of memory leaking, firefox is consuming memory when it needs it, but then not giving the memory back when its done.

No, these are pretty much textbook definitions of normal memory usage:

It is impossible to tell whether a block of memory has been freed just by looking at it. You must keep track of that yourself. An additional point is that malloc does not normally return the freed memory to the operating system; it remains owned by the process until it terminates. The process can reuse it the next time it requests more memory, but other programs will not have access to it, even if no other memory is available. As a corollary, then, the memory footprint of a program is the size of the largest allocation(s) made at any one time. Thus it is always wise to free objects you do not need, especially large ones as soon as possible, to minimize this footprint.

In addition, according to perlmonks.com (and apparently perldoc -q "program shrinks"):

You can't. On most operating systems, memory allocated to a program can never be returned to the system. That's why long-running programs sometimes re-exec themselves. Some operating systems (notably, FreeBSD and Linux) allegedly reclaim large chunks of memory that is no longer used, but it doesn't appear to happen with Perl (yet). The Mac appears to be the only platform that will reliably (albeit, slowly) return memory to the OS.

Obviously this last quote was about Perl, but being written in C and relying on C's malloc and free, it'll have the same memory issues.

I the one that has been pushing the Darwin binary compatibility project for NetBSD. This is about emulating Darwin system calls, and hence it happens at the kernel/userland boundary. We basically present to Darwin processes the system call behaviors they see on the real Darwin.

More on how it happens can be readen in a paper presented at EuroBSDCon 2005. ONLAMP also interviewed me about it. I beleive the project made the ./ headlines at least once.

Now, the project status: it is dead, because nobody has interest in it. Users got excited about the idea of running Darwin apps on NetBSD, but that excitement did not push them into testing the thing.

When I gave up, we had a fairly good support for running command-line MacOS X.2 binaries on PowerPC. The JVM would have been likely to work, for instance. I asked if people could help testing that, but got no feedback.

The project could be resurected some day, if people interest rise again. The roadmap is straightforward: support x86 Darwin and work out a solution for Aqua application to display things. There might also have been kernel API change to accomodate.

About porting this work to Linux: This is kernel developement, so I guess there would be a huge effort of rewriting things to accomodate the Linux kernel internals.

Thought even after GPL 3 comes out authors had the right to choose which license they could use.

No, the users may have a right to choose GPL3 over GPL2. Most software comes with a GPL license 2 that allows the users to choose "version 2 or later".

Linus took out this clause. Which was lucky for him, since he doesn't agree with giving away signing keys for example -

http://lkml.org/lkml/2006/1/25/273

But if you just copy pasted the default GNU supplied files into your code, then the users can choose a later version.

http://www.onlamp.com/pub/wlg/9044

Patents

These are mentioned four places in the draft. The goals here are modest: essentially, to force programmers to relinquish patent-related controls if they use free software. If they have patents on free software, they must give a patent license to anyone using it. If they have cross-licensed patents or otherwise gained rights to use patents, they must help spread this protection to the users of their software.

Now if you're a big company, and have been involved in patent litigation, you probably ended up settling it by signing an exclusive cross license agreement with the company which you fought. It looks to me as if GPL3 would force you to extend that agreement to users of your software. But the company which signed the exclusive agreement licensing patents to your company will probably not want you to do this if your users include their competitors.

E.g. consider

Company A sues company B for infringing A's patents.
Company B countersues B for infringing B's patents.
After a complicated legal battle, A and B settle. A has more patents, so B pays A a license fee each year and both of them grant each other exclusive rights to each others patents.

Now if company B is releasing GPL software with the "this version or later" clause, company C can buy a copy, opt to license it under GPL3 and ask for a license to all company B's patents. But A has to pay B to do this.

When did Linux steal this innovative technology and rename it chroot.

I've been doing PHP programming for years, and I really enjoyed working with it as a scripting language.

That said, I started playing around with Ruby on Rails. Honestly, simple tasks like database access is so much simpler to handle in RoR it's just amazing. Creating database driven web sites, with one-to-many and many-to-many relationships is at least 10x quicker than in PHP. You have to get used to the MVC style of programming of course.

I'm still doing PHP at work, but at some point will push for a switch. Check this out to see a very simple walkthrough of creating a simple web site.

Just a fan, in no way am I involved with the Ruby on Rails project itself.

Do-It-Yourself Documentation? Research Into the Effectiveness of Mailing List\s (August 19, 2006)

Rethinking Community Documentation (July 6, 2006)

Splitting Books Open: Trends in Traditional and Online Technical Documentation (September 23, 2004)

... there's vnconfig. It's less feature-rich than TrueCrypt, but it works.

There are flavours for OpenBSD, FreeBSD, and NetBSD. Here's a handy introduction.

Oracle and PostgreSQL uses MVCC to reduce the problem of locking.
MVCC makes the system a lot more scaleable with a lot of writing going on.
http://searchwarp.com/swa9860.htm
http://www.developer.com/open/article.php/877181
http://www.postgresql.org/docs/8.2/interactive/mvc c.html
http://www.onlamp.com/pub/a/onlamp/2001/05/25/post gresql_mvcc.html

Microsoft SQL Server 2005 also have some support for MVCC, but I haven't read up on that one. Microsoft SQL Server before 2005 did not have it.

You can easily notice the advantage of MVCC when compering MySQL and PostgreSQL. MySQL is fast until it gets a lot of writes and then it get slow until it dies. PostgreSQL have a more stable curve and can handle a lot more load because MVCC make the writes do not lock the reads.

This was a major advantage for Oracle and it probably still is because MS SQL Server 2005 is still a new product. MySQL is also catching up, but slower.

A binary blob is an opaque binary object from a 3rd party, for which no source code is available. To quote Jonathan Gray of the OpenBSD team: "Drivers that are binary-only or contain a binary-only portion (binary blob) run on the computer, in the computer's memory. They typically run at the most privileged security level possible due to their requirements to talk to system memory and the like. This gives them access to anything on your system, and if they screw up it can be a disaster.... People who use binary drivers become dependent on the vendors who provide them for fixing bugs and if a vendor decides to drop the driver, you're out of luck. Not running the latest hardware with the latest approved software? Sorry, too bad"

During EuroBSDCon 2004 Jordan Hubbard, manager of BSD Technologies for Apple, said:
1) BSD is missing a port for hardware architecture without a MMU, and he invited the NetBSD folks to work on that.
2) FreeBSD still has a naive audio framework. He said that if developers think that users only want to listen to MP3s, well, okay. Otherwise, we can do better.

You can see one slide wi

Memcached is an excellent suggestion -- especially since it is a distributed cache. Of course, there is overhead; some time ago, I did a series of tests using ApacheBench, trying to establish just how big the performance penalty is.

In purely local tests (i.e. ignoring network overhead) performance dropped 40% with the introduction of memcached. Over a rather slow 10 Mbps LAN, the performance degradation was only 10%. Note that memcached was still local to the server in the second series of tests -- only the request from ApacheBench went over the LAN.

Much of the memcached overhead was due to marshaling; in the non-memcached version, all objects lived entirely in memory. Increasing the number of objects in memcached 10 times resulted in a massive 70% performance drop for the LAN-based tests.

So, if you cache few objects (or plain strings), and there is little communication between the machines in your server farm, memcached performance will be close to pure in-memory performance. On the other hand, if there is lots of local I/O to handle a request, and you maintain a complex set of objects in memcached, you will take quite a hit.

The above is not the fault of memcached -- it is just that when designing distributed systems, you are actually trying to reduce the amount of communication inside the cluster. This is similar to multi-threaded design, where you must try to reduce the number of threads and especially their interaction with each other (I covered this in one of my articles for O'Reilly).

In my system (FlightFeather) I do maintain quite a lot of in-memory state to improve performance. For example, a special subclass of the float type (this is in Python) helps create a fast session cache. In addition, the operating system helps when you are using files directly, by maintaining a cache on its own. The most important thing, however, is to try to generate static content for frequently accessed material. The authors of memcached already know that static content is "boring, easy" (PDF; see page 30). If you want reliability and performance, boring and easy is where you want to go :-)

The big thing Falcon brings is MVCC which allows safe simultaneous reading and and writing without locks.

Here is a good explanation of PostgreSQL's MVCC.

Stas Bekman wrote a good article on the subject - http://www.onlamp.com/pub/a/onlamp/2006/10/12/asyn chronous_events.html

For a moment, let's imagine that paintings could be perfectly duplicated.

And let's say that the Mona Lisa was under an equivalent license to the BSD.

If an unknown artist tried to change it, they would probably not go very far. Mainly because why see a Da Vinci knock off when you can see the real thing? But if they had a reputation, like say, Andy Warhol, they could paint multiple Marilyn Monroes in multiple colours, or they could re-use the image of the Mona Lisa (yes, I know that would change the significance of the painting, but go with it).

The reason to fear someone taking your stuff and holding it is mitigated by the fact that they are competing with the genuine article. Only big players have an advantage. And similar to the example, they could have just made their own standard from scratch, or they could use yours as a base. Which one would you prefer to work with or reverse engineer?

"I wouldn't worry about a closed fork harming the community; I think that's a self-punishing form of idiocy." - esr

For personal usage, this is a reasonable technique. Our research has shown that 95% of deliveries from Windows machines are spam. However, if you are considering using fingerprinting in a business or service provider setting, rejecting connections from Windows machines is a bad bad horrible idea. Microsoft Exchange is run by almost as many companies as Sendmail these days (trust me, we've surveyed 400,000 mail servers to determine this). Blocking them all will result in many unhappy end users.

However... fingerprinting can be a very useful technique to identify a bad sender when nothing else is known about it. For example, with our connection management software, you can configure it to throttle (i.e. slow down, traffic shape, etc.) connections from Windows-based hosts if the host has no previous good reputation. See an overview of the technique in this OnLAMP article by Stas Bekman.

NOTE TO SELF USE PREVIEW :op

I use bsd ports on a daily basis, and it is pretty weak, you can specify no X11 with portage:

USE="-X" emerge imagemagick

See nice and easy. Ports is very unstable with patching etc, I shouldn't have to go through:

cvsup -g -L 2 /etc/cvsup_ports
portversion -l " portupgrade -Rra

Which btw usually breaks half the packages in the system, additionally I have to watch out for questions since ports doesn't remember my original install settings, it doesn't take much account for dependencies, on several occasions recently I have patched a freebsd system using ports and found one or more packages are broken after the install, additionally at the end my pkgdb is corrupted and I have to go through the whole process of rebuilding it.

Gentoo is much more simple:

emerge --sync && emerge -uD world

Additionally providing you didn't pass USE during the build it will build according to your original settings.

In my opinion ports is the worst package system out there, even a bsd developer agrees that ports isn't that great, however, whatever floats your boat, opinions are like as*holes everyone has one, personally I like portage, if you prefer ports go with whatever works for you. FreeBSD as an operating system is great, but I would prefer to use portage for bsd as my package manager.

You can run Irix binaries on NetBSD/sgimips. See http://www.onlamp.com/pub/a/bsd/2002/08/08/irix.ht ml for more information, and check out the NetBSD port's page at http://www.netbsd.org/Ports/sgimips/.

There is no 'won't be'... It -is- incompatible.

From http://www.onlamp.com/pub/a/onlamp/2005/09/22/gpl3 .html?page=2
"Even small changes from version 2 of the GPL will result in an incompatible license. Two slightly different licenses, each saying that modified versions of a program must be distributed under the same license, are inevitably incompatible."

There are some software that say or 'gpl v2 or any later version' but if even 1 package (ie: the kernel) doesn't say that, then the whole distro can forget it.

That sounds very exciting, but will .NET 3.0 actually embrace Web 2.0, and make it easier to write Web 2.0 applications? If not, then people who want to use Ajax will continue to switch to things like Ruby on Rails.