sourcefrog

Whitespace handling in XML

In The Annotated XML Specification, Tim Bray explains a common confusion about whitespace in XML:

XML has an incredibly simple rule about how to handle white space, that is contained in this one sentence: "If it ain't markup, it's data." Under no circumstances will an XML processor discard some white space because, in the processor's opinion, it is not "significant".

Let's look at our white space example again:

<p>Little boys, ingredients for: <ol> <li>Snips,</li> <li>snails,</li> <li>puppy dogs' tails.</li> </ol> </p>

An XML processor will pass the application not just the title and the ingredients, but all the white space characters you can see before the <ol> and <li> tags, and also the line-end characters you can't see; in this case, 7 of them. (But note that an XML processor will clean up the line-ends as described in the next section, so while apps are going to have to wrestle with white space, they won't have to deal with CR-NL on windows and CR on Mac and NL on Unix.)

This behavior is going to cause some surprises and problems for XML users and programmers, because we've come to expect (as a result of working with SGML and HTML) "insignificant" white space to auto-magically vanish.

On the other hand, those who've actually worked with real SGML tools will generally approve of XML's behavior, because it has an important virtue, namely that the rule is simple and anyone can understand it: all white space gets passed through, always.

posted Wed 31 Mar 2004 in /software/xml | link

Can you have too many choices?

jdub points to the New Yorker review of Select All.

posted Wed 31 Mar 2004 in /issues/quality | link

Sakura

Credit: Horms

posted Tue 30 Mar 2004 in /photo/nature | link

arch rocks: mirroring (updated)

There are plenty of good free software developers in the world who don't have big machines on good pipes where they can put their CVS server or downloads. People outside of the US often don't realize just how slow the combination of a modem and intercontinental latency can be. A former Prime Minister called Australia the "arse end of the world" for a reason.

Anyhow, generally what has happened until now is that these developers either find a bigger project like gnome.org or samba.org to host them, or they sign up for something like Sourceforge. Now Sourceforge is a pretty valuable thing, but it has been patchy recently. If that's where your CVS is hosted, you don't have much choice but to just not commit while it's offline.

Another drawback is that if you put CVS on sourceforge, then every time you diff or commit it needs to go all the way to California and back. This is pretty slow. When I did this over a modem, it would take a good fraction of a minute just to diff a reasonably small tree. It is annoying. It grinds you down.

What I really wanted was to have my working repository close by: either on my own disk, or at least in the same city. At the same time, I wanted my public tree to be on a fast machine on a fat pipe.

I suppose I could have kludged it up using cvsup or rsync but they're not completely satisfying solutions.

Finally, GNU Arch solves this, in a truly elegant way. Anyone can mirror a public archive. ("Archive" in Arch ~= "repository", it holds the history of changes.) In fact, several sites such as sourcecontrol.net have set up to just mirror all the open source software they can find.

(If you want to follow another developer's work closely, you can mirror their archive onto your own machine, and their entire history is available for quick consultation, even when you're offline. Conversely, and unlike Bitkeeper, you are not *required* to keep their full history if you don't want it. If you merely want to download their most recent tree, or the patches to update to the most recent tree, that's what you get.)

Other people mirror just intermittently, as a backup in case a primary archive is lost. Even the humblest programmer can now adopt Linus's backup technique: write good software, and the world will do your backups for you!

What's more, because changesets are strongly GPG-signed, people using the archive can feel sure that they're getting the changes as the original author wrote them, without any accidental or intentional modifications.

Microsoft wrote a while ago that free software development scales up to the size of the internet better than Microsoft's own processes. Arch removes the scalability bottleneck of a single CVS server.

This is a really cool thing.

posted Tue 30 Mar 2004 in /software/vc/arch | link

"Some of my best friends are pornographers"

jmason writes that SonicWall classifies his site as porn. Sourcefrog.net is for "software downloads" — I think there's an implication that it's slimely Windows "freeware", not free software.

Best of all, 2600.org is the government. The conspiracy is deeper than we suspected...

posted Tue 30 Mar 2004 in /issues/censorship | link

Interview in Builder Magazine

ZDNet is reprinting an interview I did with Brendon Chase for Builder magazine. I'm pretty happy with how it came out:

Microsoft are now shipping GPLed software! That�s a little amusing after all the nasty things they've said about the GNU GPL, but it's basically a good thing. Just about all technology companies are now working in open source to at least a small degree. This is a remarkable change from just five years ago, when most people were very skeptical that it would ever take off. Seeing Microsoft ship open source software is a bit like seeing the Berlin Wall fall. After so many years of denial and propaganda, they're finally saying (very quietly) “you know, a bit of freedom can be good”.

What advice would you give to other developers who want to get involved in open source software?

MP: A good way to start is to report or try to fix bugs that you find when you're using free software. You can learn a bit about how the software works and how the community works, and you might even get your bug fixed. Free software maintainers will often be very happy to hear problem reports, if you include useful information and do it politely.

That page come up with a Microsoft ad saying that Windows is 11%-22% cheaper than Linux. 11%, eh? Not "10%", or "about 10%", but exactly 11%. That's a pretty precise number. It's almost like they just made it up or something.

posted Tue 30 Mar 2004 in /personal | link

Eulogy for Hypercard

posted Mon 29 Mar 2004 in /software/nostalgia | link

Arch rocks: working on untrusted machines

Sometimes you need to do some development work on a machine you don't really trust. I seem to most often find myself in this situation when I'm trying to fix a portability problem by working on an exotic machine lended by some kind person. Another case might be that you're at someone else's house or office while travelling and want to do a little work or fix a bug they're experiencing.

One way you can do this for CVS is to copy your SSH key on, or forward SSH authorization from some other machine. Now, from this machine where you're doing development, you can get checkouts and commit your changes back.

But a problem is that this requires giving access to your SSH key to a machine which I don't really trust to not be compromised or have keystroke loggers. I don't really think it's hostile but at the same time I am not completely happy to let it see a key which allows changes to all my repositories, reading my mail, etc.

Under CVS you can get an anonymous checkout, and then perhaps mail yourself the diffs. It's OK. It's tolerable for small changes, but if you want to do more than one commit then it's pretty annoying. I suppose you can work around that by using Quilt along with CVS.

Under Arch, you can just treat yourself on that machine as another untrusted committer with their own archive. Make your changes, including renames and permission changes, and commit them to a local archive. When you're done, put that archive somewhere where it can be read later, or mail the changesets to yourself. Later on, review them and merge them in. At no point does your SSH or GPG key have to go onto the untrusted machine for you to be able to do regular development. I think that's pretty damn cool.

posted Mon 29 Mar 2004 in /software/vc/arch | link

blacklist forbidden URLs

A large majority of spam now contains a URL: either pointing to some kind of store where suckers can spend money, or carrying images or web bugs, or something else. A quick count shows the string "http" in over 90% of recent spam.

I'd like a spamassassin plugin that scans messages for URLs, resolves the URL, and then checks whether the URL is in a blacklisted IP space. As a start you could just check against the usual Spamhaus lists; eventually it might want to be turned

Tracking by source IP is not working so well anymore. It's too easy for spammers to send through a compromised Windows machine or open proxy. Websites, however, are a bit more established, possibly need to be on larger machines, and need to be pointed to by DNS. I suspect there are fewer of them and they move more slowly.

It's a shame SA is in Perl...

I guess Bill Stearn's blacklists come close to this, but I think listing IP blocks might be a little better than listing domains.

The most recent crap mentions http://railway.cosmic.demarcate.excretory.breast. d.bunny.deere.halfoffsalenow.biz/.

This IP is in the SBL. As of now, the Stearns blacklist blocks mail from that domain, but not mail mentioning that domain.

(Actually I think I would be pretty happy just not seeing any mail from .biz, or indeed anyone who has a bizness.)

Looking through spam missed by SpamAssassin, I see one case which would have failed, which is a supposed porn site on Geocities. It's dead now, and presumably was dead by the time I looked at the mail.

Another loophole is a goatse-style redirector: http://g.msn.com/0AD0000G/573055.1?http://128jyw.com/?rd=12&e=

That's really MSN's problem though.

posted Mon 29 Mar 2004 in /issues/spam | link

signal:noise?

I received this email. This is the *entire* mail body, with only the organization name removed:

Your e-mail has been received and will be attended to in due course.
                                                                                
                                                                                
**********************************************************************
                                WARNING
                                                                                
This email message and any attached files may contain information
that is confidential and subject of legal privilege intended only for
use by the individual or entity to whom they are addressed.   If you
are not the intended recipient or the person responsible for
delivering the message to the intended recipient be advised that you
have received this message in error and that any use, copying,
circulation, forwarding, printing or publication of this message or
attached files is strictly forbidden, as is the disclosure of the
information contained therein. If you have received this message in
error, please notify the sender immediately and delete it from your
InBox.
                                                                                
**********************************************************************

posted Fri 26 Mar 2004 in /random/humour/nerdy | link

SCons rocks

As Tim says, SCons absolutely rocks:

Automatic header dependency checks across directories.
When you change the SConstruct file, files which would be build differently are automatically rebuilt.
It's far quicker than autoconf/automake/libtool.
It's easy to portably build shared libraries without needing to depend on a mess like libtool, which doesn't even work on non-Unix platforms.

In all (or almost all) the situations where make would force you to say make clean and rebuild, SCons will just do the right thing.

One more cool feature: if it recompiles a file, but produces the exact same object file (because there were only whitespace or comment changes) then it knows not to relink dependent programs, because it checks the hash of intermediate files. How cool.

posted Fri 26 Mar 2004 in /software/scons | link

Wikipedia on Whitlam

Wikipedia's feature article today is on Gough Whitlam

posted Fri 26 Mar 2004 in /issues/politics | link

(fwd) Awesome story

Scott writes:

I just thought I would share a little experience of mine that you might like.

Last night I was flying back from Boise on Alaska Air. I had my laptop (Compaq Evo N800w) up and running RH9 and had just started to play Tux Racer for the first time ever after doing a little filesystem housekeeping when one of the flight attendants, a woman who had to be at least 55 if not 60 years old, stopped, commented that the game looked cute, and asked me where I got it. I told her I was running linux and it came with the OS. She responded that she had tried to put linux on her laptop but had problems getting the display working right. Needless to say, my jaw dropped. She goes on to tell me how she's running Win98 but using Opera instead of IE and she is just getting of MS telling her what to run and she's sick of their security holes that you can drive a truck through. After chatting a bit longer I asked her when she had tried to install linux on her laptop and she told me it was probably four or five years ago! She went back to Win98 because she didn't feel she was up to building a new kernel which was what she thought she might have to do. Keep in mind this flight attendant looked like she had to be at least 55...

Hmmm. Maybe my Mom is ready for a linux desktop afterall. ;)

posted Fri 26 Mar 2004 in /software/linux | link

unixism for today

Find user who run commands from their .forward files:

# locate /home/\*.forward|xargs grep -l '|'|xargs less

posted Thu 25 Mar 2004 in /software/shell | link

smartbear

smart bear software have good-looking graphical tools for diffs and code history on Windows.

posted Thu 25 Mar 2004 in /software/vc | link

clear text

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: Message in clear text
 
THIS=20DOCUMENT=20IS=20AUTOMATICALLY=20GENERATED.
PLEASE=20DO=20NOT=20RESPOND=20TO=20THIS=20MAIL.
=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20QANTAS=20E-TICKET=20ITINERA=
RY=20AND=20RECEIPT
=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
ABN=2016=20009=20661=20901
=20=20INTERNATIONAL=20CUSTOMERS=20REQUIRE=20THIS=20DOCUMENT=20FOR=20IMMI=
GRATION,

posted Wed 24 Mar 2004 in /random/humour/nerdy | link

CMPI - WBEM Common Management Provider Interface

CMPI is a C programming interface for writing "provider modules" that plug in to a WBEM management server. It's kind of analogous to the Apache module interface in scope and content. You might use this to write a provider module that can issue management information about SMART disk drives. The module can do either a polled mode, reporting on the drives in response to a request, or interrupt mode, where it generates an "indication" message when something happens.

This interface is meant to be standardized across all providers and managers allowing for them to evolve separately.

WBEM is technically pretty good but the documentation can be hard to get a grip on. DMTF's determined efforts to make sure it remains obscure (e.g. requiring registration to read documentation) are not helping. I think I should add more links here.

posted Fri 19 Mar 2004 in /software/wbem | link

GNOME: Java, Mono, or C++?

Havoc writes on the issue of a high-level application language for GNOME.

In the Linux desktop world, there's widespread sentiment that high-level language technologies such as garbage collection, sandboxed code, and so forth would be valuable to have and represent an improvement over C/C++. [...]

To me the way to create something that most of the community can swallow is to stick strictly to open source, unencumbered technologies. This means there's a level playing field; anyone can hire developers to contribute to the technologies, anyone can fork if they have to. It's essential that our high-level language technology have no single owner with irrevocable control.

Open source creates this level playing field, and that's why it historically works as a way for diverse companies and individuals to collaborate on software projects. Without the level playing field, everyone gets too paranoid and fragmentation or stagnation are inevitable. [...] Aside from IP issues, Microsoft controls the .NET platform. They will always be ahead, and it will always be tuned for Windows. This is the wrong direction for free software, if we want to win the war, and not only some battles.

Even if we use some unencumbered ideas or designs from the .NET world, we should never define our open source managed runtime as a .NET clone.

I think he's right that Python, Perl and Ruby are not it. They're great for particular applications but I wouldn't want to write an office suite in them. On the other hand, if neither C# or Java work out for licensing reasons, Python might be a good pick.

Rick Kitts is not convinced, but I think he's being too pessimistic.

You can often see open source projects having design arguments, personal fights, making mistakes or changing their mind in public. It's easy to conclude from this that they're really schizophrenic or hostile. I don't think they are. Similar discussions occur inside companies. The only big difference is that open source projects do it in public.

In particular, Microsoft probably had a similar discussion paper before deciding on their strategy for C#. Indeed, you can see them doing this sort of thing in the Halloween papers.

GNOME have pretty consistently been able to have a dicussion, make a decision and move on. I think they will be fine here.

posted Thu 18 Mar 2004 in /software/gnome | link

The (lack of) future of Java

I was just reading cbrumme's very interesting Microsoft blog.

I think one thing you can see here is that Microsoft are absolutely clearly trying their standard pattern #1 on Java: let Sun invent it, wait for it to be adopted, design something a little better and much less open, and ram it through the ISV/IT channel. Embrace, extend, extinguish.

(This sounds a bit harsh on CLR, which from my limited reading does seem to be the product of rather more intelligent thought than your average paperclip. But I don't think this is going to be decided primarily on technical merit.)

So the big question is, does Sun have the brains and/or balls to play the one gambit that gives Java a chance of survival: open source Java?

The only commercially interesting operating systems these days are either open source or Microsoft. Sun's Java runtime can't be included in free operating systems like Debian, and Microsoft doesn't (?) ship the current JDK. So Sun have just wilfully excluded themselves from being preinstalled on the two most important platforms. Way to go.

(OK, so failing to be preinstalled is not the end of the world. But it's not helping. Having a standard JRE on each release might make Sun less sloppy about cross-version compatibility than they have been to date.)

posted Wed 17 Mar 2004 in /software/languages/java | link

HP to Introduce Linux-Based PCs in Asia

http://apnews.myway.com//article/20040316/D81BJEVO0.html

TOKYO (AP) - With an Asia rollout announced Tuesday, Hewlett-Packard Co. becomes the first major PC maker to offer desktop computer lines running the open-source Linux operating system.

The move by HP, the world's largest PC maker, with about 17 percent market share, could be a threat to Microsoft Corp. (MSFT), maker of the market-dominating Windows operating system.

Linux is posed to become an especially strong competitor to Windows in Asia.

Japanese, South Korean and Chinese officials have expressed concerns about becoming too dependent on Windows - especially in the government sector - and are exploring alternatives.

HP said its Linux PCs would be targeted at "emerging markets, where Windows PCs are not used so widely."

[...]

Redmond, Wash.-based Microsoft has other problems in Asia, including an investigation by Japan's fair trade watchdog on suspicion of monopoly law violations.

Agents from the trade commission raided Microsoft's Japanese offices Feb. 26, looking for evidence that the company attached improperly restrictive conditions on its software deals with computer makers.

posted Wed 17 Mar 2004 in /software/industry | link

social climbing

Went indoor rock climbing. It was good. I got up some walls I wouldn't have thought I could. I feel much more sporty now than I did a couple of years ago. Now I do some kind of exercise every day or two: swimming, netball, walking, now climbing. This is still perhaps not very sporty by some standards. I don't know what changed in me.

posted Tue 16 Mar 2004 in /personal | link

Things We Lost In the Fire

Low's Things We Lost In The Fire, on Kranky, is great. If you like Kranky records, you'll like this.

posted Tue 16 Mar 2004 in /media/music | link

arch wins

Colin, you were right: arch really is beautiful. I think the simplicity of the design borders on genius.

posted Tue 16 Mar 2004 in /software/vc/arch | link

commerciality

EnviroMission CEO Roger Davey in The Australian:

"The success of the pre-feasibility study signals the go-ahead towards full commerciality and is one of the most significant decisions in the progress of solar tower technology to date,"

posted Tue 16 Mar 2004 in /issues/bad-language | link

Hey Lady, Hang Up The Phone!

Kind of old, from brutal hugs:

Is it wrong to laugh at things like this? This woman crashed her car while on her cell phone. She crashed into a cell phone store. She was an EMT.

I've had my close encounters with people just like this woman. I've almost been killed on my motorcycle by people talking on the cell, watching TV, eating, reaching into the back seat, etc. And so I say better her than me.

posted Tue 16 Mar 2004 in /motorbikes | link

warped visions

There's some interesting stuff at warpedvisions.org, including the autoblock plugin I'm using to write this. I wonder if it works?

Apparently it does. Yay.

posted Tue 16 Mar 2004 in /blogs | link

email fees and viruses

aj discusses the problems of pay-per-email transmission:

One objection to email fees is related to email viruses: if every email you send costs a cent, and you get a virus that sends out 20,000 emails you've just lost $200. That sucks. Fortunately, that's straightforward avoidable by limiting the amount of money your computer can access without your authorisation (by way of password, eg). If you limit the amount of money your computer has access to to $5, that's 500 emails you can send before you have to worry about recharging your account (more presuming you get sent some emails), and if you do get infected by a virus, you only lose $5, which is a nuisance, but not a big deal. Odds are you lose that much in time anyway. And even better, instead of sending out 20,000 emails, you've only sent out 500, reducing the problem globally.

I don't think this is a very good fix. Suppose that this plan was adopted and we had paid-for stamps on email. Suppose as well that, as at present, a lot of spam is sent through compromised end-user machines.

Presumably there would be some way for your email client to prompt you to buy some more stamps when you run low. Perhaps Outlook pops up a little dialog prompting for your credit card. There is already a large increased risk that people will become accustomed to typing in their credit card when their MUA asks, and some users will store their credit card number in the MUA's memory.

An analog for this already exists in trojan dialler programs, where a compromised machine calls a premium-rate 1-900 or 0055 number to generate a large phonebill, some fraction of which gets back to the scammer. It seems like the law or policy here is that because the user's system really did dial the number, the user is liable for the call. Presumably the same would happen for spam.

In particular, it would be easy for a trojaned machine to ask the user to buy more stamps, but to actually buy $500 rather than $5, and to use the rest for sending spam.

We are no longer in the c1998 situation of lazy ISPs hosting spammers. Instead, most spam (cite?) is sent from compromised machines. An adequate defence these days needs to cope with a horde of compromised zombies. I don't think payment systems do that.

Organized crime is attracted by the combination of money and weak systems. Adding more money to the email system will probably make the problem worse.

On the one hand, the risk on losing $500 might make people more likely to worry about computer security. On the other hand, it is a powerful disincentive to even think about installing an email client that can make payments.

If you're in an organisation, and you don't want your 1000 staff members all losing $5 at once to a virus, you can setup your mail server to require manual authorisation if anyone tries sending more than a couple of emails every few minutes. That's possible now, of course, but there's no reason to do it: it doesn't stop the organisation from getting infected by the virus, since it already is, and it doesn't much matter that other people get infected.

Another way to produce that backpressure would be to sue or prosecure someone for negligently continuing to transmit viruses. I think it is fairly clearly negligent to send mail; it might even be covered by existing computer crime legislation.

Maybe a good way of looking at this is thus: email postage is free to you as long as the number of emails you send is less than the number of spams you receive.

So we only need to worry about high-volume senders. Most people won't need to send more than say 100-200 emails per day, and it would be a good start to cap dial-up/DSL users to that. Perhaps organizations which do need to send in large volumes should pay a bond to some kind of underwriter.

posted Tue 16 Mar 2004 in /issues/spam | link

More VC comparisons

Zooko and David Wheeler have also written comparisons of new free version control / SCM systems. We seem to be broadly in agreement.

posted Fri 12 Mar 2004 in /software/vc | link

Bizarre spammer tricks

An apparently real yacht advertisement, with porn links. I wonder what degree of overlap there is between luxury motor yacht buyers and horse sex fanatics? You might think they'd have more luck here.

posted Fri 12 Mar 2004 in /issues/spam | link

jmason agrees

posted Fri 12 Mar 2004 in /books/taoup | link

TAOUP: Open source and code reuse

I think the best and most insightful section of TAOUP is that on why software reuse drives programmers to free software:

Why do programmers reinvent wheels? There are many reasons, reaching all the way from the narrowly technical to the psychology of programmers and the economics of the software production system. The damage from the endemic waste of programming time reaches all these levels as well.[...]
Beneath the surface gloss of their demo applications, the components he is re-using seem to have edge cases in which they behave unpredictably or destructively — edge cases his code tickles daily. He often finds himself wondering what the library programmers were thinking. He can't tell, because the components are inadequately documented — often by technical writers who aren't programmers and don't think like programmers. And he can't read the source code to learn what it is actually doing, because the libraries are opaque blocks of object code under proprietary licenses.
Newbie has to code increasingly elaborate workarounds for component problems, to the point where the net gain from using the libraries starts to look marginal. The workarounds make his code progressively grubbier. He probably hits a few places where a library simply cannot be made to do something crucially important that is theoretically within its specifications. Sometimes he is sure there is some way to actually make the black box perform, but he can't figure out what it is.

This should be familiar to anyone who's tried to make nontrivial use of a complex closed library.

I wrote a while ago about why this meant the Objective C / "Superdistribution" idea of reusable closed components was doomed from the start.

Of course RMS has been saying this all along...

I think this is one reason why many of the best programmers want to work on open software, and will do it in their spare time even if they can't get a satisfactory day job. If you're going to bother to write the best code you can, you don't want it to be lost in a couple of years when the original project is killed for business reasons.

posted Thu 11 Mar 2004 in /books/taoup | link

A.M. Kuchling on TAOUP

Python hacker amk reviews The Art of Unix Programming:

In spots there's too much history. [....] I don't really think anyone should really care about the fact that Uniforum, Ultrix, or NeWS once existed, whatever their influence has been.
There are occasional splashes of self-congratulation or silly assertion. My favorite silly assertion is a mention that "Commercial Unix distributions that have [removed] the BUGS section or euphemizing it ... have invariably fallen into decline."

I agree: it is an excellent book, though flawed by overindulgence of the author's pet ideas and projects.

posted Thu 11 Mar 2004 in /books/taoup | link

LWN: SCO and Public Perception

LWN has a good article on SCO, stock prices and the media:

Anybody who was paying attention during the dotcom bubble knows better than to attribute too much rationality to stock prices. That notwithstanding, a stock market is an efficient machine for integrating the opinions of a large number of unrelated people. SCO's stock price peaked briefly at $22.29 in October, when the BayStar deal was announced. At that time, the company's market capitalization was a little over $300 million. Given that SCO has no business left other than its Linux-related litigation, its stock can be seen as a sort of call option on SCO's lawsuits. Even at its peak, SCO's stock price represented a perceived chance of collection of less than 10%. If the company were truly set to collect billions, it would not be valued in the millions.

posted Thu 11 Mar 2004 in /issues/sco-vs-linux | link

SBLIM - Standards Based Linux Instrumentation for Manageability

SBLM pronounced "sublime" and is an acronym for Standards Based Linux Instrumentation for Manageability. The goal of this project is to provide a complete Open Source implementation of the CIM Schema for Linux Systems. SBLIM is a project maintained by the IBM Linux Technology Center and is licensed under the CPL.
Why is it needed?
Today, looking at GNU/Linux systems (and others) reveals a rather fragmented and incoherent picture regarding Systems Management and Manageability. There are basically two reasons:
Proprietary format and locations: Information about system resources are spread all over the place and have their unique format. This includes files in the /etc directory tree, entries the /proc filesystem and so forth.
Lack of common concepts: It is virtually impossible for a Systems Management application to manage system resources without knowing implementation details. Example needed? How about configuring a device in need of special run-time options.

This needs less enterprise-speek if it's going to be adopted, but I think the core idea may be good.

posted Wed 10 Mar 2004 in /software/wbem | link

What you want...

From groklaw, quoting "SCOSource" VP Gregory Blepp:

"After that lawsuit, SCO will initiate actions against major users of Linux throughout the world, including in Spain, to establish legal precedent, because, explained Blepp, Linux users want legal certainty that SCO is right.

It is really remarkable how often I meet Linux users and developers who say, “I wish SCO were proved right”.

"Gregory G. Blepp said to EFE that SCO is not going to go against home users or educational use, only against large companies and institutions that are getting benefits from Linux without paying. It added that, with these actions, SCO isn't trying to attack open source code, only to defend its rights and that, in fact, it works together on Linux projects like Apache and Samba.

It ought to be fairly easy to establish how many Samba committers work at SCO. By my count it's about zero, but it might be a little less.

He figures that currently there are in the world between 2.5 and 3 million users of Linux who need to pay SCO for a license."

posted Fri 5 Mar 2004 in /issues/sco-vs-linux | link

Archives 2008: Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May