We have weathered the last dozen email viruses; certainly, we can last through this one. My simple mail server is receiving hundreds of these messages an hour, and I'm plenty irritated by the whole thing. Nonetheless, I have not one tear for SCO.
SCO has been steadily losing credibility since their first accusations. For OSS developers to initiate a DDOS on SCO would be seen as a strike below the belt, and a completely unnecessary one as well.
This is one of the reasons that I don't believe it was created by anyone in the OSS community. The general concensus has been to wait for IBM to knock SCO clear out of the ring in just under two weeks. A DDOS at this time would be completely unexpected and anticlimactic. It's more likely a private joke in the distributed spam world, and locating and bringing those idiots to justice would be time well spent.
Any attempt to involve yourselves in this will be viewed as complicit behavior. Do not get this mess associated with Open Source developers in any way, shape, or form. The culture and purpose of worm authors and OSS developers are completely orthogonal and must remain so.
SCO has enough enemies to worry about, and they can point fingers all they want. They do not deserve an olive branch, they did not ask for one -- do not take the bait and proactively offer one. You will lose fingers.
An excerpt from a recent text by a prominent internet anthropologist.
After observing a contradiction between the official ideology defined by script kiddie culture and the actual behavior of worm writers, I examine the customs which regulate the 'mad pr0pz' and authorship of virus software. I show that they imply an underlying theory of property rights homologous to the '1 ownz joo!' principal of acquisition. I then relate that to an analysis of the script kiddie community as a 'loudest fart wins' culture in which participants compete for prestige by DDOS'ing public resources, defacing prominent websites, and bragging about their exploits in IRC. Finally, I examine the implications of this analysis for conflict resolution in the culture, and develop some prescriptive implications. - Eric S. Raymond,
Fat Worms and Flat Worms, Musings on 1337 Script Kiddies by an Accidental Bystander
The strings program just shows the obvious text in the application. Frequently this provides copyright notices, and some fingerprint-like identifiers. When code is bulk copied, these strings are usually replicated. The correlation in strings between two applications can be very good evidence of code copying when little to no obfuscation has taken place.
Here's a snippet of strings from the WindowsXP ftp client:
tenex image binary ascii PASS %s@%s USER anonymous TYPE %s TYPE %s %s ... snip... SetConsoleMode GetConsoleMode CreateFileA Sleep CharToOemBuffA OemToCharBuffA @(#) Copyright (c) 1983 The Regents of the University of California. All rights reserved.
Compare this to ftp client on my box...
Error creating temporary file, oops Filename provided by server doesn't match pattern `%s': %s Extremely long filename from server: %s Mode: %s; Type: %s; Form: %s; Structure: %s Verbose: %s; Bell: %s; Prompting: %s; Globbing: %s Store unique: %s; Receive unique: %s Hash mark printing: %s; Use of PORT cmds: %s Connected for proxy commands to %s. CWD command not recognized, trying XCWD ... snip... $NetKit: netkit-ftp-0.17 $ $Id: glob.c,v 1.9 1999/10/02 13:25:23 netbug Exp $ @(#) Copyright (c) 1985, 1989 Regents of the University of California. All rights reserved. $Id: main.c,v 1.15 1999/10/02 13:25:23 netbug Exp $ $Id: ruserpass.c,v 1.9 1999/10/02 19:12:33 dholland Exp $
Notice that the feel of the strings are different. The copyright notices are intact. A programmer can gather some information about what language the code was written in, how they may have handled certain problems in a generic way, but little can be reverse engineered. Also interesting to note is that both are based on BSD code as evident from the University of California copyrights.
A single unix admin can hold down more computers than an MCSE so it's not unusual that they command a higher salary. It's a simple matter of efficiency.
At the last "all Microsoft" shop I worked, the six or seven MCSE's spent all of their time trying to keep the company's Windows-based servers limping along. They never looked happy, worked 12 salaried hours a day, and no matter how hard they worked, at least one monitor in the server stacks always had a glaring BSOD or startup failure message waiting for dismissal. Failure was endemic, and resetting production servers midday was a weekly occurrence. On at least two occasions, none of the 500+ employees could login for 6 or more hours because ActiveDirectory took a dump. I genuinely felt for those guys because not only was it not their fault, but they had absolutely no way to diagnose the problem more or less fix it. The repository had been continually corrupting itself for over a month, so even after restoring from backups, ADS refused to read the data. In the end, we paid Microsoft a lot of money to send their own people out to repair things.
At my current job, we have one guy managing a comparable number of unix/linux servers under considerably higher load, and because the systems require so little attention, we've been able to put him on other projects as well.
In total, my previous employer was spending almost a quarter-million a year in wages, just maintaining their internal servers. We spend about $50K and have surplus resources available. In fact, we could easily double our capacity without hiring another admin if the need arose.
The word you are looking for is not "race." It's "culture." The statement "black people are better dancers than white people" is flawed even as a generalization. Similarly, the idea that asian students are smarter than their white peers is also a dim characterization. Identifying the difference between two individuals is one thing. Identifying the difference between two groups is much more complicated. Properly attributing the difference requires a look at the respective cultures.
A simpler explanation for those who got lost in the long words.
Each day, the sun rises and sets a little more to the north or little more to the south depending on the season. The days of the year where the sun reaches the most north or most south are solstices. When the sun crosses the middle, they're equinoxes. The official "spring equinox" is when the sun crosses the middle moving north. If you were to call that the first day of the year and beginning counting days, you will total up 365 days between equinoxes. After about four years of that though, you'll be off by one, so you'll need to add an extra day. This is called "intercalation."
One could make a rule to add an extra day every four years, but after 100 years or so, they would be foward one day too many. Skip the 100th year, and after 400 years, they'd be 1 day behind. The rule as it stands is every fourth year, except years ending in '00, plus every 400th year. Easy enough, but still not quite right.
Because the rule is not quite right, it will never be perfectly accurate. But if you follow the rule exactly, you can tell that January 1, 1601 was Monday for instance. You can also tell exactly how many days are between now and January 1, 2400 because you know which years are leap years.
The method of watching the sun and adding leap years as necessary is a great way to stay exactly on time, but really inconvenient if you need to predict exactly how every year will fall for the next 100 years or so.
Some people say so what, just live. Who cares if your birthday in 20 years is on a Tuesday. Tax collectors care... Money lenders care... Hallmark greeting cards cares... Calendar makers care... The Vatican cares... So we use the 400 year rule and call it the Gregorian Calendar. It works well enough.
As for TT, UT, UTC, TIA, ET, and a number of other time standards, well... the important thing is that we're now using very accurate clocks for counting seconds and we've determined that the earth does not spin all the way around in exactly 24 hours no matter how closely we've measured it. In fact, it had slowed down for awhile and now seems to have gotten back up to speed.
We determine the difference between the atomic clock and the earth by watching the stars go by, and after spinning, spinning, spinning, we watch the atomic clock and the sky, and if it doesn't come out just right, we assume the clocks are right and the earth is wrong. To make up the difference, we throw in an extra second once every 6 months as necessary. It hasn't been necessary since 1999 which was the crux of the article.
This is very interesting. The technique I present for starting a project using cvs import is documented in both books that I keep as reference (neither of which is handy at the moment). Presumably, the root checkout method is documented elsewhere (the cvs documentation itself perhaps). This does explain the 1.1 revision and 1.1.1.1 vendor branch tag.
For what it's worth, the vendor tag and branch has never been an issue for me. In a manner of speaking, I am the vendor, although that's not what was original intended. Additionally, most of my projects have dozens of branches, so it's a non issue. The overhead of a branch is minimal, and I'm a firm believer that no one should ever be afraid to tag or branch whenever the need arises.
As such, I stand by my recommendation that people new to CVS use the cvs import command for starting new projects even if an extra tag is created, and particularly if it's the only branch tag they ever use.
I recently had to implement code to convert terrestrial time (TT) to martian solar day (MSD). Some interesting tidbits in that research follow.
As you might guess, the extra days in leap years help keep our calendars synchronized with our actual position about the sun (heliocentric longitude). This is called intercalation, and the general rules governing the gregorian calendar cover 400 year periods. Other methods exist which are in a sense more "accurate," but less useful for predicting future dates. Fortunately, the earth is pretty regular in its movement around the sun.
The 0 degree mark for heliocentric longitude occurs at the vernal equinox, an event that can be easily determined from earth, and has been for centuries. In the Iranian calendar, the new year begins on the day of the vernal equinox. Since this event occurs later in the day each year, eventually an extra day must be added. Such calendars are based on observation rather than rule-based model and consequently are implicitly self-calibrating.
Leap seconds, as pointed out, are an entirely different beast, and are meant to shore up the discrepency between our actual rotation and the atomic clocks we use. The current offset is 22 seconds slow officially. Oddly enough, a NASA document from 1997 uses a value of 63 seconds as the offset between TT (terrestial time) and UTC (Greenwich Mean Time). Another from 2000 shows a 32.184 second offset from TT to TIA (atomic). It doesn't exactly correlate or add up, and I'm not precisely sure why that is. Perhaps someone could enlighten me on the matter.
Curiously, our leap years follow the mathematical model while our leap seconds follow the observation method of calibration. Consequently, you can determine the correct date in the future, but not the correct second.
There are two environment variables to be aware of, CVSROOT, and CVS_RSH. Setting CVSROOT isn't necessary, but it simplifies the cvs command line a little bit for first time users. I keep these variables in my.profile, but often as not, I use the cvs -d parameter to specify the exact repository. Once checked out, the project will remember where it came from. I use SSH for remote repositories, so the CVS_RSH environment variable is always set.
Generally, you may wish to start with a simple project and check it in before beginning your work in earnest. The fewer files the better, and if you've already run configure and have hundreds of non-source build files in the directory already, it can be time consuming to remove them, despite helpful make targets. I try to start with as few files as possible, and add all my source files explicitly.
[~me]$ mkdir foo; cd foo [foo]$ touch ChangeLog [foo]$ cvs import foo me initial [foo]$ cd..; rm foo
From here, one merely needs to checkout the project, add, and commit source files.
[~me]$ cvs checkout foo [~me]$ cd foo [foo]$ vi Makefile foo.c [foo]$ cvs add Makefile foo.c [foo]$ cvs commit
Obviously, a good bit of the first part could be scripted... I don't bother since I find project setup somewhat zen anyway. I enjoy the ceremony of it, and it's not a daily task anyway.
I develop dozens of projects concurrently. Keeping all the development details straight can be difficult, particular when reapproaching a project that has been untouched for several months. The ability to back out non-obvious design mistakes, start speculative development branches, and distribute projects across multiple machines, depending on where I am at any point in time has made single version control a necessity for me.
Starting a project in CVS is simple.
Create a directory. Maybe add a descriptive text file or two. Run cvs import from within the directory. You'll then need to do a checkout, and you're ready to begin adding makefiles, source code, autoconf delights/madness. For what it's worth, I always rename the original directory before the checkout in case CVS has a glitch. Older CVS balked at overwriting the files; maybe that's still the case.
The last reason that I use source control even for projects that I am the sole developer is that I have on occassion, deleted critical files by mistake, and had to reimplement entire classes/modules under duress. It's a rare event, but with source control, I'm less stressed over the possibility of screwing up.
As for the last statement, the differences between licensing with Sparc and licensing GPL software is not my concern. My argument is solely the proper intrepretation of the GPL. Secondly, I recognize that you are referring to an agreement between the author and the user. Discounting UCITA in Maryland, there is no legal precedence suggesting that the user is a licensee. This is particularly the case since the user does not need a license to use software anymore than he needs to a license to read a book. Either the software is sold and the Doctrine of First Sale presides (the user is not a licensee), the software is leased and contract law presides (the user is a licensee), or the software is provided without obligation and neither preside. In all three cases, Copyright Law is still enforceable. The GPL leverages copyright to offer the user a license, but can only do so under circumstances where copyright has teeth -- namely in copying, modifying, and redistributing the software.
As far as your hypotheticals go, they are certainly interesting. After breaking it down, there really is no serious loophole here, but I present it anyway for completeness.
There are two valid cases of distribution here. In the first case, you purchase the work. In the second case, you receive a copy for free. You cannot lease the work, since that violates the GPL outright (section 6). In the first case, Doctrine of First Sale applies. You may sell, not distribute, a binary without its source. In the second case, First Sale does not apply and there is no condition for redistribution without accepting the GPL. This analysis will focus solely on the first case, as the second is moot.
Doctrine of First Sale, not Copyright Law, states that you may resell what you have purchased, and you do not need to accept any provisions of the GPL to do so. If you purchase a CD set, you may sell only the binary disks if you choose. Whether you are downloading and burning your own disks or purchasing them from someone else, this apparent loophole will become less attractive after the following argument.
One, if you purchase those CD's or download the packages from someone else, your margins will be thin and business prospects low since anyone can easily undercut you. Moreover, your customers can get the source code directly from your distributor so neither the GPL nor Open Source in general is really impacted. Theoretically, you would even be complicit with section 3c, other than the non-comerrical clause which would in this case be unenforceable anyway.
Two, if you purchase every copy you sell, and repackage them, you may find it extremely difficult to claim Fair Use under First Sale. If you don't purchase them, you do not even have First Sale to fall back on. At the minimum, your records will be subject to subpoena, including proof of every purchase, proof of every distinct copy or download, complete auditing of all your expenses and sales receipts. If you've sold more than you bought -- or can prove that you bought -- you could be found guilty of copyright violation or breach of the GPL or both. Sounds risky, and you also run the risk of violating the trademarks of the original distributor. See the CleanFlicks case for an example of how many ways this can go wrong.
Three, if you create a dummy "distributor" that only deals with you and will not provide source code to your customers, then this "distributor" will be in violation of the GPL section 3b. This is most dangerous. If during the discovery phase of the lawsuit, this becomes known, both you and the "distributor" will be treated as a single party and sued jointly for treble damages.
Contract law is never black and white. If it makes it to court, a judge will have to determine whether the parties are in fact enjoined, what the contract means to each party, and how it will be resolved both legally and equitably. This is where your actions will be collectivel
I am familiar with the contract argument, and it's a reasonable one if we're talking redistribution. The problem is that your argument is shot through because the following statement is in fact incorrect.
In all reality, nothing but the GPL gives the user ANY rights to the software. Copyright law would normally forbid the user the software in absence of an agreement to transfer a copy.
Physical theft not withstanding, the possessor of the copyrighted work has no obligations with regard to how he received the work. If an upstream distributor has violated copyright law, that distributor alone is liable. If any contract exists, it is between that distributor and the author. Under no circumstance can the final recipient be entangled in such a contract, more or less be held liable. This is very well established, and you will not be able to find any legal precedence that shows otherwise because it does not exist.
To be exact, a contract does exists between all legal distributors of a work and the owner of the copyright. This is true regardless of whether we're discussing manuscripts, music, or software. Similarly, no contract exists between the author and final recipient. You, as a consumer, do not have a contract, implicit or otherwise, between the author and yourself, for every book, CD, DVD, and tape in your possession. This is not only good, but a legal necessity.
In the eyes of the law, you are presumed to act as though all distributors are legally authorized by the author, and as a result, legal attention is focused solely on distributors who are in fact violating copyright law. If this were not the case, commerce of copyrighted works would be impossible.
More importantly, if you receive a book, paid for or not, from the author, his agent, a store, a website, or the dumpster, that copy becomes your property. You may read it, burn it, eat it, or consume it in any way you choose. In total, you may use it, and there are no restrictions on that use. What you may not do with it, is make copies and redistribute them. That is the point where copyright law gets involved. Copyright has no power to restrict usage, and neither does the GPL.
An individual only approachs the contractual aspects of the GPL if he redistribute the software, and only then because the author has publicly extended an offer. The author cannot legally prevent the end-user from doing anything except making copies; hence, if the end-user does not redistribute the software, the offer is void, and there is no contract.
The GPL governs redistribution, not use. If you have a copy of GPL'd source, regardless of how you got it, you may use it. Period. If you wish to redistribute it, you may do so, if and only if you accept the GPL. It's a very simple concept.
An end-user cannot run afoul of the GPL even accidentally as he does not create and distribute binary packages. If he did, he would not be an end-user.
You can mirror it without permission. You do need to provide attribution and cannot charge money for it. See the Creative Commons link at the bottom of the Groklaw website.
As for bandwidth bills, I just donated money to them yesterday. I recommend that everyone do the same.
I actually got hit on while buying my dual 2.0GHz G5. As it was my first Mac following a long series of PC's, my first thought was that things really are different in the Mac world. Now, had she been attractive, there'd be more story to tell, but as it is, I think she was just drooling over the box anyway. -Hope
Actually, I'm a Linux user myself, and I just bought a Mac G5 running OS X 10.2. If Linux is camping, the Mac is a beach resort. That said though, I wouldn't call it a step up so much as paying for better service.
Also, while it's nice, and everything is pretty, as far as unix stuff is concerned, I still had to install Fink to get anything close to the usability and capability I already have in Linux. As an example, I needed to demux and composite over 10K frames of uncompressed video. The G5 ate through that right away... but it was all command line tools that did the work. I'm certain that a $1000 professional package will do that, and the Final Cut Express that came bundled (well $200 off) might even do it, but this is something that I need to automate. I don't think that Final Cut is going to talk to cron.
More to the point, when I'm working the Mac, I miss the power and immediate control of Linux. When I use Linux, I growl over the USB issues, the weird way the CD-ROM closes without warning under Nautilus, the situation with recompiling drivers for Alsa and nVidia every time the kernel is upgraded.
In total, I can get my work done on both machines. A quick comparison based on my work use...
Both have completely working media players. Curiously, MPlayer and XMMS are more featureful than Quicktime and iTunes. As of OS X 10.2, I can't play any AVI's or Ogg files on the Mac.
Both have working developer environments. I still prefer vi, make, and gcc, but there's XCode (which I haven't installed because 10.3 is still in the box) and Eclipse for people who are into that sort of thing.
The Mac may be polished (and I'm loving every minute of it), but my Linux boxes are work horses. They're assets, not liabilities, particular where time and resources are concerned.
Oddly enough, the only machine that is currently causing me to pull my hair out is the Windows XP box running on a $8K Dell workstation that's now on its fourth install. Since I have to activate it each time, I wonder if I'll eventually run out. For some reason, whenever deadlines approach, the machine slows, behaves eradically, and fails leaving me to spend an afternoon reinstalling and restoring from backup. It's not a hardware problem; we have three such machines, and they'll all have about a 6 month life-span. I use my machine more aggressively, so I'm on the 3 month cycle.
So to sum up, if you can afford it, buy a Mac G5 anyway. It sounds like you deserve it. But don't pitch the Linux box just yet. Take a break!
I've been using Linux since 1997... nothing you've said rings true to anything I've experienced. Whether large-scale research computers or massive high-availability servers in critical business infrastructure, Linux is there today, right now in fact.
I'll buy that Linux is not a dominant player on the desktop, but the idea that Linux isn't kicking in heads in the server environment just doesn't hold up. The only hardware on which Linux doesn't have a solid edge is speciality kit like high-end Sun and IBM equipment which really is not representative of the general market anyway. What's more, IBM is closing that gap on their equipment right now.
I contend that for large businesses, migration costs and support are the real limiting factors in switching to Linux. It's certainly not for technical reasons. Solaris and AIX have some features that do not appear in Linux, but generally, they are there to support the hardware. Since commodity hardware is cheap, people have been selling off their over-priced kit, dropping their expensive, recurring service contracts, and lowering their overall TCO. Need examples? Check Redhat, Suse, and IBM's press releases.
Anybody paying for a Posix-compliant operating system nowadays is wasting their money. They should be spending it on support contracts since that's what they really need - assurance.
This just doesn't seem to be the case. First off, RPMs are built for specific distributions, and unless the package is completely inert, will be labeled as such. Go to rpmfind.net - every package has its original distribution listed. Go to a website that offers RPM downloads and you'll find rh7.x, rh8, rh9 packages listed. If not, then they are generally safe to install or you'll get a dependency error. Check the website docs or email the maintainer if you're unsure. If it comes up often, they'll change the website to make it clear.
As for Window's users, you're just as likely to get hosed by a third-party application install as a foreign RPM, so I figure it's a wash. On Windows, it is still a problem that newly installed programs will occasionally downgrade DLL's in the system folder. If you leave the happy confines of your distribution, you're taking risks. No two ways about it.
Finally, users should Read The Manual. Especially, if they are not serious computer users.
The IT department for one of my clients remotely updated three production machines on Friday evening, after which the computers inexplicably rebooted. They never came back up. What's more, these machines were responsible for the company's entire back office data feed. Without it, they are effectively running blind. The $15K it cost them to get those machines back up, tested, and re-certified won't hurt them in the long run, but there's nothing quite like bleeding out your jugular to give you a better appreciation of just how blantly MS leaves your assets swinging the breeze.
-Hope
Somebody Left the Grail Beacon On...
on
CNet on WinFS
·
· Score: 1
How long has Microsoft been working on this now? It's not going to happen. WinFS is fighting against entropy and human nature. It's going to lose.
The moment you enter meta-data it becomes stale. Unless the meta-data is derived from the data itself, it cannot and will not stay synchronized without manual intervention or diligent application coding.
If the application is responsible for maintaining the tags, only standard meta-data fields can be used or applications will not interoperate. Can we expect the equivalent of ID3 tags for all user data? Of 100 potential industry-standard tags, how many will you present to the user to fill out before writing a file to the OS?
Will you be able to search on vendor-specific tags? What if there are over 2000 unique tags on the system? Was that "creation-date" or "creation-time"? If I specify both will I get the intersection or the union of the data? This is starting to sound a lot more like report writing than a google search. SQL queries are designed to operate on normalized data of a known format. That's not going to happen without OS level enforcement which brings us to the next problem.
If the operating system is responsible, somebody has to write code to parse these files and extract the relevant tags. Will that code be signed? What user context will it run in? What about proprietary file formats? Who decides what code does the parsing? More importantly, what happens if the data is invalid or worse, deliberately malformed. IE was compromised this past year by a flaw in the MIDI library. Can we expect to be rooted by simply indexing a rogue file?
Then there is the issue of having multiple copies of the same file with changes too subtle for either the application or the operating system to detect. Presently, we distinguish these files by name, but we also frequently distinguish by location in the filesystem hierarchy. For instance, all images under directories red, green, and blue may have slightly different hues. How shall we tag these? And if they are generated by a batch script?
The two most important attributes of a file are the user given name and the position within the filesystem. In fact, those are the only two details that general applications today will even ask for before saving. Why? Because it's hard enough getting people to choose a better name than "letter.doc".
In closing, I don't see how any amount of indexing and tagging will justify the overhead on the filesystem, the burden on developers, or the potential security risks that this scheme entails. MS will lose a lot of momentum working on WinFS.
There are better approaches to the "lost file" problem.
The x86 architecture is not designed to be virtualized, at least not for code expecting to run in ring 0. The work that VMWare must do to emulate ring 0 without the guest OS coming unglued is simply daunting, including traps for every detail from setting and clearing interrupts to modifying page tables. A lot of that work requires predicting code execution paths and dynamically modifying the code at runtime. It's a real nightmare.
Plex86 promised to provide an open-source solution to this problem, but the last time I checked (which admittedly was awhile ago), they were planning on using bochs to emulate ring 0. This is not exactly satisfactory, but I don't blame them. It's a hard problem, one for which VMWare is entitled and deserving of reward for having solved.
So how do you get real virtual host performance out of your x86 machine? You design around the flaw. Operating systems that are written to run in ring 1 and call the Xen hypervisor instead of performing ring 0 functions will run at nearly full speed. Those that do not or will not make these compromises will see at best, an emulated ring 0. It's really that simple.
Personally, I don't see much value in being able to run any arbitrary operating system in a single environment if it's impossible to get real, sustained performance out of it. Cross-platform testing: sure. Kernel debugging: certainly. But host virtualization? What I want is the capability of running multiple hosts simultaneously, and if the operating system needs delibrate tweaking to make this possible, then obviously that's the direction to go.
To answer the gripes of people who want just that transparent hosting of unmodified OSes, it would be interesting to see a follow-on project for dynamically modifying the guest OS to thunk-out all the privileged calls to use the Xen extensions directly rather than trapping exceptions as they do now. This would probably not work well for page tables modifications, so a hybrid system might be employed. In this fashion, the best of both worlds may be achieved.
Twenty years ago I was 11. By then I already had 5 years of coding experience, mostly assembly, and a bit of Basic. Everything I knew about code came from reading books, reading other people's Basic code, and disassembling binaries. At no point was I actually aware that there were people out there fighting to make possible what I largely took for granted... the complete availabilty of source code as well as the unrestricted ability to read, modify, and distribute it.
As an adult, I nearly gave up coding altogether. I felt like a farmer without my own land. I owned no share of the programming tools that I used daily. All the API's were immutable, opaque, and hostile (VFW comes to mind).
Then I found Linux, and from there, the FSF and GNU. Beyond a doubt, without the work of Stallman and everyone fighting for Open Source, I'd be doing anything but writing code today. And aside from my family, few things are more integral to who I am than writing software. I was born to code.
So thank you Richard! It took me awhile to find everyone, but now that I'm here, I'm glad you started when you did. That said, if we had to start from scratch today, I would be part of it.
Blaster grappling with the firewall... there seems to be a misconfiguration somewhere... And *BAM*, Blaster slips right through to take an unpatched webserver... hate to be the admin for that box...
Blaster looking around for more targets... seems confused by the DMZ... looking... looking... and he's *IN THERE*... slips through a stale RPC connection to a developer box...
Making quick work of development...
over to Q&A...
back to management and sales...
And score! Laptops in sales. Those will be handy on Monday when they're at client sites...
Back to the webserver... saturating that connection... just punishing that connection. How much pain can this ISP take!?
::COMMERCIAL BREAK::
This program brought to you by Microsoft. When you think Security, don't laugh, say "Trustworthy Computing" three times and tap your shoes together like *this*. And Norton Antivirus. We can't protect you, but at least you'll feel like you've done *something*.
Slashdot Mirror
We have weathered the last dozen email viruses; certainly, we can last through this one. My simple mail server is receiving hundreds of these messages an hour, and I'm plenty irritated by the whole thing. Nonetheless, I have not one tear for SCO.
-Hope
SCO has been steadily losing credibility since their first accusations. For OSS developers to initiate a DDOS on SCO would be seen as a strike below the belt, and a completely unnecessary one as well.
This is one of the reasons that I don't believe it was created by anyone in the OSS community. The general concensus has been to wait for IBM to knock SCO clear out of the ring in just under two weeks. A DDOS at this time would be completely unexpected and anticlimactic. It's more likely a private joke in the distributed spam world, and locating and bringing those idiots to justice would be time well spent.
-HopeOS
Any attempt to involve yourselves in this will be viewed as complicit behavior. Do not get this mess associated with Open Source developers in any way, shape, or form. The culture and purpose of worm authors and OSS developers are completely orthogonal and must remain so.
SCO has enough enemies to worry about, and they can point fingers all they want. They do not deserve an olive branch, they did not ask for one -- do not take the bait and proactively offer one. You will lose fingers.
-Hope
Here's a snippet of strings from the WindowsXP ftp client:
Compare this to ftp client on my box...
Notice that the feel of the strings are different. The copyright notices are intact. A programmer can gather some information about what language the code was written in, how they may have handled certain problems in a generic way, but little can be reverse engineered. Also interesting to note is that both are based on BSD code as evident from the University of California copyrights.
-Hope
A single unix admin can hold down more computers than an MCSE so it's not unusual that they command a higher salary. It's a simple matter of efficiency.
At the last "all Microsoft" shop I worked, the six or seven MCSE's spent all of their time trying to keep the company's Windows-based servers limping along. They never looked happy, worked 12 salaried hours a day, and no matter how hard they worked, at least one monitor in the server stacks always had a glaring BSOD or startup failure message waiting for dismissal. Failure was endemic, and resetting production servers midday was a weekly occurrence. On at least two occasions, none of the 500+ employees could login for 6 or more hours because ActiveDirectory took a dump. I genuinely felt for those guys because not only was it not their fault, but they had absolutely no way to diagnose the problem more or less fix it. The repository had been continually corrupting itself for over a month, so even after restoring from backups, ADS refused to read the data. In the end, we paid Microsoft a lot of money to send their own people out to repair things.
At my current job, we have one guy managing a comparable number of unix/linux servers under considerably higher load, and because the systems require so little attention, we've been able to put him on other projects as well.
In total, my previous employer was spending almost a quarter-million a year in wages, just maintaining their internal servers. We spend about $50K and have surplus resources available. In fact, we could easily double our capacity without hiring another admin if the need arose.
-Hope
The word you are looking for is not "race." It's "culture." The statement "black people are better dancers than white people" is flawed even as a generalization. Similarly, the idea that asian students are smarter than their white peers is also a dim characterization. Identifying the difference between two individuals is one thing. Identifying the difference between two groups is much more complicated. Properly attributing the difference requires a look at the respective cultures.
-Hope
A simpler explanation for those who got lost in the long words.
Each day, the sun rises and sets a little more to the north or little more to the south depending on the season. The days of the year where the sun reaches the most north or most south are solstices. When the sun crosses the middle, they're equinoxes. The official "spring equinox" is when the sun crosses the middle moving north. If you were to call that the first day of the year and beginning counting days, you will total up 365 days between equinoxes. After about four years of that though, you'll be off by one, so you'll need to add an extra day. This is called "intercalation."
One could make a rule to add an extra day every four years, but after 100 years or so, they would be foward one day too many. Skip the 100th year, and after 400 years, they'd be 1 day behind. The rule as it stands is every fourth year, except years ending in '00, plus every 400th year. Easy enough, but still not quite right.
Because the rule is not quite right, it will never be perfectly accurate. But if you follow the rule exactly, you can tell that January 1, 1601 was Monday for instance. You can also tell exactly how many days are between now and January 1, 2400 because you know which years are leap years.
The method of watching the sun and adding leap years as necessary is a great way to stay exactly on time, but really inconvenient if you need to predict exactly how every year will fall for the next 100 years or so.
Some people say so what, just live. Who cares if your birthday in 20 years is on a Tuesday. Tax collectors care... Money lenders care... Hallmark greeting cards cares... Calendar makers care... The Vatican cares... So we use the 400 year rule and call it the Gregorian Calendar. It works well enough.
As for TT, UT, UTC, TIA, ET, and a number of other time standards, well... the important thing is that we're now using very accurate clocks for counting seconds and we've determined that the earth does not spin all the way around in exactly 24 hours no matter how closely we've measured it. In fact, it had slowed down for awhile and now seems to have gotten back up to speed.
We determine the difference between the atomic clock and the earth by watching the stars go by, and after spinning, spinning, spinning, we watch the atomic clock and the sky, and if it doesn't come out just right, we assume the clocks are right and the earth is wrong. To make up the difference, we throw in an extra second once every 6 months as necessary. It hasn't been necessary since 1999 which was the crux of the article.
-Hope
This is very interesting. The technique I present for starting a project using cvs import is documented in both books that I keep as reference (neither of which is handy at the moment). Presumably, the root checkout method is documented elsewhere (the cvs documentation itself perhaps). This does explain the 1.1 revision and 1.1.1.1 vendor branch tag.
For what it's worth, the vendor tag and branch has never been an issue for me. In a manner of speaking, I am the vendor, although that's not what was original intended. Additionally, most of my projects have dozens of branches, so it's a non issue. The overhead of a branch is minimal, and I'm a firm believer that no one should ever be afraid to tag or branch whenever the need arises.
As such, I stand by my recommendation that people new to CVS use the cvs import command for starting new projects even if an extra tag is created, and particularly if it's the only branch tag they ever use.
-Hope
I recently had to implement code to convert terrestrial time (TT) to martian solar day (MSD). Some interesting tidbits in that research follow.
As you might guess, the extra days in leap years help keep our calendars synchronized with our actual position about the sun (heliocentric longitude). This is called intercalation, and the general rules governing the gregorian calendar cover 400 year periods. Other methods exist which are in a sense more "accurate," but less useful for predicting future dates. Fortunately, the earth is pretty regular in its movement around the sun.
The 0 degree mark for heliocentric longitude occurs at the vernal equinox, an event that can be easily determined from earth, and has been for centuries. In the Iranian calendar, the new year begins on the day of the vernal equinox. Since this event occurs later in the day each year, eventually an extra day must be added. Such calendars are based on observation rather than rule-based model and consequently are implicitly self-calibrating.
Leap seconds, as pointed out, are an entirely different beast, and are meant to shore up the discrepency between our actual rotation and the atomic clocks we use. The current offset is 22 seconds slow officially. Oddly enough, a NASA document from 1997 uses a value of 63 seconds as the offset between TT (terrestial time) and UTC (Greenwich Mean Time). Another from 2000 shows a 32.184 second offset from TT to TIA (atomic). It doesn't exactly correlate or add up, and I'm not precisely sure why that is. Perhaps someone could enlighten me on the matter.
Curiously, our leap years follow the mathematical model while our leap seconds follow the observation method of calibration. Consequently, you can determine the correct date in the future, but not the correct second.
-Hope
or
Generally, you may wish to start with a simple project and check it in before beginning your work in earnest. The fewer files the better, and if you've already run configure and have hundreds of non-source build files in the directory already, it can be time consuming to remove them, despite helpful make targets. I try to start with as few files as possible, and add all my source files explicitly.
From here, one merely needs to checkout the project, add, and commit source files.
Obviously, a good bit of the first part could be scripted... I don't bother since I find project setup somewhat zen anyway. I enjoy the ceremony of it, and it's not a daily task anyway.
-Hope
I develop dozens of projects concurrently. Keeping all the development details straight can be difficult, particular when reapproaching a project that has been untouched for several months. The ability to back out non-obvious design mistakes, start speculative development branches, and distribute projects across multiple machines, depending on where I am at any point in time has made single version control a necessity for me.
Starting a project in CVS is simple.
Create a directory. Maybe add a descriptive text file or two. Run cvs import from within the directory. You'll then need to do a checkout, and you're ready to begin adding makefiles, source code, autoconf delights/madness. For what it's worth, I always rename the original directory before the checkout in case CVS has a glitch. Older CVS balked at overwriting the files; maybe that's still the case.
The last reason that I use source control even for projects that I am the sole developer is that I have on occassion, deleted critical files by mistake, and had to reimplement entire classes/modules under duress. It's a rare event, but with source control, I'm less stressed over the possibility of screwing up.
-Hope
As for the last statement, the differences between licensing with Sparc and licensing GPL software is not my concern. My argument is solely the proper intrepretation of the GPL. Secondly, I recognize that you are referring to an agreement between the author and the user. Discounting UCITA in Maryland, there is no legal precedence suggesting that the user is a licensee. This is particularly the case since the user does not need a license to use software anymore than he needs to a license to read a book. Either the software is sold and the Doctrine of First Sale presides (the user is not a licensee), the software is leased and contract law presides (the user is a licensee), or the software is provided without obligation and neither preside. In all three cases, Copyright Law is still enforceable. The GPL leverages copyright to offer the user a license, but can only do so under circumstances where copyright has teeth -- namely in copying, modifying, and redistributing the software.
As far as your hypotheticals go, they are certainly interesting. After breaking it down, there really is no serious loophole here, but I present it anyway for completeness.
There are two valid cases of distribution here. In the first case, you purchase the work. In the second case, you receive a copy for free. You cannot lease the work, since that violates the GPL outright (section 6). In the first case, Doctrine of First Sale applies. You may sell, not distribute, a binary without its source. In the second case, First Sale does not apply and there is no condition for redistribution without accepting the GPL. This analysis will focus solely on the first case, as the second is moot.
Doctrine of First Sale, not Copyright Law, states that you may resell what you have purchased, and you do not need to accept any provisions of the GPL to do so. If you purchase a CD set, you may sell only the binary disks if you choose. Whether you are downloading and burning your own disks or purchasing them from someone else, this apparent loophole will become less attractive after the following argument.
One, if you purchase those CD's or download the packages from someone else, your margins will be thin and business prospects low since anyone can easily undercut you. Moreover, your customers can get the source code directly from your distributor so neither the GPL nor Open Source in general is really impacted. Theoretically, you would even be complicit with section 3c, other than the non-comerrical clause which would in this case be unenforceable anyway.
Two, if you purchase every copy you sell, and repackage them, you may find it extremely difficult to claim Fair Use under First Sale. If you don't purchase them, you do not even have First Sale to fall back on. At the minimum, your records will be subject to subpoena, including proof of every purchase, proof of every distinct copy or download, complete auditing of all your expenses and sales receipts. If you've sold more than you bought -- or can prove that you bought -- you could be found guilty of copyright violation or breach of the GPL or both. Sounds risky, and you also run the risk of violating the trademarks of the original distributor. See the CleanFlicks case for an example of how many ways this can go wrong.
Three, if you create a dummy "distributor" that only deals with you and will not provide source code to your customers, then this "distributor" will be in violation of the GPL section 3b. This is most dangerous. If during the discovery phase of the lawsuit, this becomes known, both you and the "distributor" will be treated as a single party and sued jointly for treble damages.
Contract law is never black and white. If it makes it to court, a judge will have to determine whether the parties are in fact enjoined, what the contract means to each party, and how it will be resolved both legally and equitably. This is where your actions will be collectivel
Physical theft not withstanding, the possessor of the copyrighted work has no obligations with regard to how he received the work. If an upstream distributor has violated copyright law, that distributor alone is liable. If any contract exists, it is between that distributor and the author. Under no circumstance can the final recipient be entangled in such a contract, more or less be held liable. This is very well established, and you will not be able to find any legal precedence that shows otherwise because it does not exist.
To be exact, a contract does exists between all legal distributors of a work and the owner of the copyright. This is true regardless of whether we're discussing manuscripts, music, or software. Similarly, no contract exists between the author and final recipient. You, as a consumer, do not have a contract, implicit or otherwise, between the author and yourself, for every book, CD, DVD, and tape in your possession. This is not only good, but a legal necessity.
In the eyes of the law, you are presumed to act as though all distributors are legally authorized by the author, and as a result, legal attention is focused solely on distributors who are in fact violating copyright law. If this were not the case, commerce of copyrighted works would be impossible.
More importantly, if you receive a book, paid for or not, from the author, his agent, a store, a website, or the dumpster, that copy becomes your property. You may read it, burn it, eat it, or consume it in any way you choose. In total, you may use it, and there are no restrictions on that use. What you may not do with it, is make copies and redistribute them. That is the point where copyright law gets involved. Copyright has no power to restrict usage, and neither does the GPL.
An individual only approachs the contractual aspects of the GPL if he redistribute the software, and only then because the author has publicly extended an offer. The author cannot legally prevent the end-user from doing anything except making copies; hence, if the end-user does not redistribute the software, the offer is void, and there is no contract.
-Hope
Parent poster is either a troll or a fool.
The GPL governs redistribution, not use. If you have a copy of GPL'd source, regardless of how you got it, you may use it. Period. If you wish to redistribute it, you may do so, if and only if you accept the GPL. It's a very simple concept.
An end-user cannot run afoul of the GPL even accidentally as he does not create and distribute binary packages. If he did, he would not be an end-user.
-Hope
You can mirror it without permission. You do need to provide attribution and cannot charge money for it. See the Creative Commons link at the bottom of the Groklaw website.
As for bandwidth bills, I just donated money to them yesterday. I recommend that everyone do the same.
-Hope
I actually got hit on while buying my dual 2.0GHz G5. As it was my first Mac following a long series of PC's, my first thought was that things really are different in the Mac world. Now, had she been attractive, there'd be more story to tell, but as it is, I think she was just drooling over the box anyway. -Hope
Actually, I'm a Linux user myself, and I just bought a Mac G5 running OS X 10.2. If Linux is camping, the Mac is a beach resort. That said though, I wouldn't call it a step up so much as paying for better service.
Also, while it's nice, and everything is pretty, as far as unix stuff is concerned, I still had to install Fink to get anything close to the usability and capability I already have in Linux. As an example, I needed to demux and composite over 10K frames of uncompressed video. The G5 ate through that right away... but it was all command line tools that did the work. I'm certain that a $1000 professional package will do that, and the Final Cut Express that came bundled (well $200 off) might even do it, but this is something that I need to automate. I don't think that Final Cut is going to talk to cron.
More to the point, when I'm working the Mac, I miss the power and immediate control of Linux. When I use Linux, I growl over the USB issues, the weird way the CD-ROM closes without warning under Nautilus, the situation with recompiling drivers for Alsa and nVidia every time the kernel is upgraded.
In total, I can get my work done on both machines. A quick comparison based on my work use...
Both have completely working media players. Curiously, MPlayer and XMMS are more featureful than Quicktime and iTunes. As of OS X 10.2, I can't play any AVI's or Ogg files on the Mac.
Both have working developer environments. I still prefer vi, make, and gcc, but there's XCode (which I haven't installed because 10.3 is still in the box) and Eclipse for people who are into that sort of thing.
The Mac may be polished (and I'm loving every minute of it), but my Linux boxes are work horses. They're assets, not liabilities, particular where time and resources are concerned.
Oddly enough, the only machine that is currently causing me to pull my hair out is the Windows XP box running on a $8K Dell workstation that's now on its fourth install. Since I have to activate it each time, I wonder if I'll eventually run out. For some reason, whenever deadlines approach, the machine slows, behaves eradically, and fails leaving me to spend an afternoon reinstalling and restoring from backup. It's not a hardware problem; we have three such machines, and they'll all have about a 6 month life-span. I use my machine more aggressively, so I'm on the 3 month cycle.
So to sum up, if you can afford it, buy a Mac G5 anyway. It sounds like you deserve it. But don't pitch the Linux box just yet. Take a break!
-Hope
I've been using Linux since 1997... nothing you've said rings true to anything I've experienced. Whether large-scale research computers or massive high-availability servers in critical business infrastructure, Linux is there today, right now in fact.
I'll buy that Linux is not a dominant player on the desktop, but the idea that Linux isn't kicking in heads in the server environment just doesn't hold up. The only hardware on which Linux doesn't have a solid edge is speciality kit like high-end Sun and IBM equipment which really is not representative of the general market anyway. What's more, IBM is closing that gap on their equipment right now.
I contend that for large businesses, migration costs and support are the real limiting factors in switching to Linux. It's certainly not for technical reasons. Solaris and AIX have some features that do not appear in Linux, but generally, they are there to support the hardware. Since commodity hardware is cheap, people have been selling off their over-priced kit, dropping their expensive, recurring service contracts, and lowering their overall TCO. Need examples? Check Redhat, Suse, and IBM's press releases.
Anybody paying for a Posix-compliant operating system nowadays is wasting their money. They should be spending it on support contracts since that's what they really need - assurance.
-Hope
This just doesn't seem to be the case. First off, RPMs are built for specific distributions, and unless the package is completely inert, will be labeled as such. Go to rpmfind.net - every package has its original distribution listed. Go to a website that offers RPM downloads and you'll find rh7.x, rh8, rh9 packages listed. If not, then they are generally safe to install or you'll get a dependency error. Check the website docs or email the maintainer if you're unsure. If it comes up often, they'll change the website to make it clear.
As for Window's users, you're just as likely to get hosed by a third-party application install as a foreign RPM, so I figure it's a wash. On Windows, it is still a problem that newly installed programs will occasionally downgrade DLL's in the system folder. If you leave the happy confines of your distribution, you're taking risks. No two ways about it.
Finally, users should Read The Manual. Especially, if they are not serious computer users.
-Hope
The IT department for one of my clients remotely updated three production machines on Friday evening, after which the computers inexplicably rebooted. They never came back up. What's more, these machines were responsible for the company's entire back office data feed. Without it, they are effectively running blind. The $15K it cost them to get those machines back up, tested, and re-certified won't hurt them in the long run, but there's nothing quite like bleeding out your jugular to give you a better appreciation of just how blantly MS leaves your assets swinging the breeze.
-Hope
How long has Microsoft been working on this now? It's not going to happen. WinFS is fighting against entropy and human nature. It's going to lose.
The moment you enter meta-data it becomes stale. Unless the meta-data is derived from the data itself, it cannot and will not stay synchronized without manual intervention or diligent application coding.
If the application is responsible for maintaining the tags, only standard meta-data fields can be used or applications will not interoperate. Can we expect the equivalent of ID3 tags for all user data? Of 100 potential industry-standard tags, how many will you present to the user to fill out before writing a file to the OS?
Will you be able to search on vendor-specific tags? What if there are over 2000 unique tags on the system? Was that "creation-date" or "creation-time"? If I specify both will I get the intersection or the union of the data? This is starting to sound a lot more like report writing than a google search. SQL queries are designed to operate on normalized data of a known format. That's not going to happen without OS level enforcement which brings us to the next problem.
If the operating system is responsible, somebody has to write code to parse these files and extract the relevant tags. Will that code be signed? What user context will it run in? What about proprietary file formats? Who decides what code does the parsing? More importantly, what happens if the data is invalid or worse, deliberately malformed. IE was compromised this past year by a flaw in the MIDI library. Can we expect to be rooted by simply indexing a rogue file?
Then there is the issue of having multiple copies of the same file with changes too subtle for either the application or the operating system to detect. Presently, we distinguish these files by name, but we also frequently distinguish by location in the filesystem hierarchy. For instance, all images under directories red, green, and blue may have slightly different hues. How shall we tag these? And if they are generated by a batch script?
The two most important attributes of a file are the user given name and the position within the filesystem. In fact, those are the only two details that general applications today will even ask for before saving. Why? Because it's hard enough getting people to choose a better name than "letter.doc".
In closing, I don't see how any amount of indexing and tagging will justify the overhead on the filesystem, the burden on developers, or the potential security risks that this scheme entails. MS will lose a lot of momentum working on WinFS.
There are better approaches to the "lost file" problem.
-Hope
The x86 architecture is not designed to be virtualized, at least not for code expecting to run in ring 0. The work that VMWare must do to emulate ring 0 without the guest OS coming unglued is simply daunting, including traps for every detail from setting and clearing interrupts to modifying page tables. A lot of that work requires predicting code execution paths and dynamically modifying the code at runtime. It's a real nightmare.
Plex86 promised to provide an open-source solution to this problem, but the last time I checked (which admittedly was awhile ago), they were planning on using bochs to emulate ring 0. This is not exactly satisfactory, but I don't blame them. It's a hard problem, one for which VMWare is entitled and deserving of reward for having solved.
So how do you get real virtual host performance out of your x86 machine? You design around the flaw. Operating systems that are written to run in ring 1 and call the Xen hypervisor instead of performing ring 0 functions will run at nearly full speed. Those that do not or will not make these compromises will see at best, an emulated ring 0. It's really that simple.
Personally, I don't see much value in being able to run any arbitrary operating system in a single environment if it's impossible to get real, sustained performance out of it. Cross-platform testing: sure. Kernel debugging: certainly. But host virtualization? What I want is the capability of running multiple hosts simultaneously, and if the operating system needs delibrate tweaking to make this possible, then obviously that's the direction to go.
To answer the gripes of people who want just that transparent hosting of unmodified OSes, it would be interesting to see a follow-on project for dynamically modifying the guest OS to thunk-out all the privileged calls to use the Xen extensions directly rather than trapping exceptions as they do now. This would probably not work well for page tables modifications, so a hybrid system might be employed. In this fashion, the best of both worlds may be achieved.
-Hope
Twenty years ago I was 11. By then I already had 5 years of coding experience, mostly assembly, and a bit of Basic. Everything I knew about code came from reading books, reading other people's Basic code, and disassembling binaries. At no point was I actually aware that there were people out there fighting to make possible what I largely took for granted... the complete availabilty of source code as well as the unrestricted ability to read, modify, and distribute it.
As an adult, I nearly gave up coding altogether. I felt like a farmer without my own land. I owned no share of the programming tools that I used daily. All the API's were immutable, opaque, and hostile (VFW comes to mind).
Then I found Linux, and from there, the FSF and GNU. Beyond a doubt, without the work of Stallman and everyone fighting for Open Source, I'd be doing anything but writing code today. And aside from my family, few things are more integral to who I am than writing software. I was born to code.
So thank you Richard! It took me awhile to find everyone, but now that I'm here, I'm glad you started when you did. That said, if we had to start from scratch today, I would be part of it.
-Hope
Blaster at that router...
::COMMERCIAL BREAK::
Blaster at the firewall...
Blaster grappling with the firewall... there seems to be a misconfiguration somewhere... And *BAM*, Blaster slips right through to take an unpatched webserver... hate to be the admin for that box...
Blaster looking around for more targets... seems confused by the DMZ... looking... looking... and he's *IN THERE*... slips through a stale RPC connection to a developer box...
Making quick work of development...
over to Q&A...
back to management and sales...
And score! Laptops in sales. Those will be handy on Monday when they're at client sites...
Back to the webserver... saturating that connection... just punishing that connection. How much pain can this ISP take!?
This program brought to you by Microsoft. When you think Security, don't laugh, say "Trustworthy Computing" three times and tap your shoes together like *this*. And Norton Antivirus. We can't protect you, but at least you'll feel like you've done *something*.
-Hope