...I saw some of the massive ignorant egos strutting around, and couldn't just let it pass. So I post.
:-)
Look, people, Sun will never OpenSource Solaris. I do take issue with them (in particular, the marketing 'droids) initially toutting Solaris as being OpenSourced, but they have backed off this - you will note that everything in their current campaign talks about a "Free Source License" and similar terms. Yes, some people may confuse it with the Free Software movement, but face it people, 99% of people associate the word free with cost (as in beer), and not with libre (as in GNU).
Also, look at what Sun is trying to target. Essentially, they make money on hardware and services for Solaris, and no money on the OS (even when they charge for it, it's insignificant in the scheme of things). By using the SCSL, there are the following benefits:
Sun gets a new revenue stream from people wanting to make use of customized Solaris (embeded OSes and such, primarily). By opening Solaris under the SCSL, Sun makes it alot easier for VARs to evaluate using Solaris as a base technology, and the VARs save lots of money on R&D costs.
Many people get to see how an industrial-grade OS is written (warts and niceties, both). Academics may very well use chunks of it for teaching purposes, and in general, you get a better-informed developer community. This helps both Sun and the Sun-oriented developer community.
Sun retains control over Solaris branding and standardization. All the problems Linux has over standardized distros and kernel levels is avoided. The *BSDs do the same thing - one organization has veto power over what goes into the OS.
You do get bug fixes. Yes, Sun doesn't have to incorporate them into the next release of Solaris, and redistribution is limited - but see below for some notes about redistribution of such fixes.
Sun retains it's Intellectual Rights. Yeah, I know we'd all love it if we could get our gubby mitts on some of the nice stuff in Solaris, but honestly, I can see why Sun isn't interested in it. There's no real payback for them that the SCSL can't provide. Remember, Sun's goals are different than the OpenSource movements.
As a side note, please note a couple of things about distributing mods to Solaris 8 (and using Solaris code):
You can redistribute diffs however you want. Context-diffs are a bit of a fuzzy area (are the context "included code"?), but certainly, output from normal diff solaris_file.h modsol_file.h is allowed. You don't have to go through Sun to distribute these changes. You own the copyright to the diff contexts, and can license it however you want (though it better be compatible with the end-user SCSL in order to be usable by others).
Fixed software containing Solaris code must be redistributed by Sun. That is, if the Solaris grep has a bug, and you fix it, and want to distribute the whole thing, you have to submit it to Sun, who will then redistribute it on their "secure" web site. Sun doesn't own your mods - you still do. They can't use your mod in Solaris(tm) until they get permission (and possibly pay) you to do so. The way I read things, you could even conceivably charge for the fix without owing Sun royalties, though that may be wrong (I'd have to have a serious lawyer re-read the agreement). But it has to be redistributed by Sun, not you.
Yes, the Free Solaris Source Code program isn't an OpenSource movement by Sun. It has it's uses, and for that I'm happy. It definitely is limited, but for those target markets, it's a Good Thing. Maybe someday they truly will Open Source Solaris, but only when Sun sees that the advantages for Sun to Open Source outweigh the benefits they get from SCSL.
You're making a file server, and by far you're biggest problem is going to be I/O bottlenecks (disk & network), NOT CPU. In fact, I can keep a 100Mbit connection fully flooded with SMB traffic with a lowly Dual PPro200 system. So the second CPU isn't necessary at all. Here are my recommendations (and I've done this before):
Use Seperate NT Boxes for Domain Controllers. If you're going to be serving Windows clients, it's alot easier to set up 3-4 cheap PCs (say $1k each (new)) to be dedicated BDC/PDCs. Since you can locate the DCs near (in network terms) the clients, you're going to get much better authorization and login response times than using the Samba server as authorizer.
As a correllary to the above, put a dedicated pipe from the Samba box to the PDC - slap in an extra network card for each box, and give the samba server a dedicated route to the PDC - this will help speed things up quite a bit.
Disk Speed is Everything - As another poster suggested, use a hardware Raid 10 solution. Raid 5 will be ok, but 10 will be much faster. In either case, USE SCSI. Don't even think about IDE. Get 10,000rpm disks if you can, but more 7200RPM disks is better than fewer 10k disks. Go for a minimum of Ultra2 LVD drives, or Ultra3 if you can.
Use multiple NICs - Your other bottleneck will be the network. At the minimum, use a different NIC for each major network segment. If you can, use a switch that allows for NIC bonding (like Cisco 2900s), so you can aggregate the NICs (it's alot cheaper to get 4 100Mbit NICs bonded into a 400Mbit channel than to try for Gigabit Ethernet).
Get lots of RAM - this will be used for disk caching, which speeds things up alot. A minimum of 512MB is acceptible, and 1GB might be nice, depending on what else is going on.
If the machine is doing pure Smaba serving, and you are using external PDCs, get the lowest-speed CPU you can (which will probably mean at least a 500Mhz one). It will be more than sufficient. Use the money for your disk subsystem.
If you want to do something like virus scanning, or PDC work, or even DNS serving, look into a better CPU, especially if your going to be doing Mail on the box (which is a CPU hog). In general, though, I think you'd be better off with sticking to a limited-function box and 1 CPU.
Product Plug: I like Compaq Proliants. They're very Linux-friendly, and they have the nice extras you want in a server. Here's a suggested config:
Honestly, I can't see it being any more risky to leave a computer on unattended (which is what you're really asking) than leaving the TV set on.
The big thing here is common sense. A computer is an electrical device (indeed, one that consumes a fair amount of power). You should treat it as such. By far your greatest hazzard is a short-circuit that sparks, which can result in a fire.
Don't put it near easily flamable materials. Keep it away from curtains, your bedspread, the paper wastebasket, etc. Don't drape stuff over it.
Don't put it in a closet with clothes. In fact, I would recommend against putting it in a closet, period, unless you have specifically prepared the closet for holding electrical devices.
Give it good clearance and ventilation. A properly cooled system is much less likely to malfunction, and a clean airflow helps immensely.
Keep it away from water and gas sources. Duh. Not in the kitchen, not in the bathroom, near the washer, etc. Also, not underneath that large window where it rains in all the time...
Keep it clean. Probably the second leading cause of electrical problems is foreign crap in the device. Ideally, try to keep the machine somewhere where it won't suck in all the dust bunnies. Dust filters are good idea, and you should clean the machine periodically, particularly in places that have central air (as that tends to circulate dust).
Watch the wiring! The biggest cause of electrical fires is wiring. Make sure you're not over-taxing the circuit the machine is on. Fine out how many Amps the circuit you're on can take, and then go make sure you're not exceeding that by all the devices plugged in. Make sure the electrical socket(s) you're using is new, and has good wiring. Make Sure It's Properly Grounded!
Power protect it! At the minimum, buy a high-quality surge protector. Not the $7 ones, but the $30 ones that can handle a damned big spike. A small UPS is probably better. Don't plug a huge amount of devices into the strip/UPS. Don't daisy-chain the strips.
Keep it secured from children or pets! Many people forget about this, but not only can they be a cause of unexpected crashes, but they can harm themselves and/or possibly start a fire.
All in all, common sense. One thing here: if you can possibly arrange it, put the computer in a room that doesn't have carpeting - and definately avoid rugs. It cuts down on dust and crap, and is slightly safer (linoleum, tile, concrete, or even a wood floor is much less likely to catch fire from random sparks).
Most of this advices goes for all computer-related equipment (hubs, telco stuff, UPSes...), though the low-power and general safety of small networking gear makes it possible to safely stow in closets (but do try not to stack clothes/inflammibles on it) - I usually recommend putting it in something similar to a metal milk crate.
If you can count on that, then you have any number of access/content control mechanisms. This is exactly what PKI (Public Key Infrastructure) addresses.
Fundamentally, you don't want to validate the machine, you're interested in the user. So forget network id, et al.
As others have pointed out, the obvious solution is Kerberos, from MIT. It was specifically designed to solve the problem you have. However, you have to build kerberos into your application, so it's not simple, and neither is the setup.
The second most popular solution are Personal Digital Certificates (NOT SSL Certificates). These are tied into Web Server authentication (for the most part), but can be used as a generic authentication mechanism. Depending on what you want, they can be relatively cheap and uncomplicated, or it can get pretty hairy. Look at Thawte for a decent example - also, check out the iPlanet Certificate Server for some relevant info. Honestly, this is probably the easiest way to do what you want, IF you can do a web-based service. It won't be free, but if you scrape around, you can probably get it in place for a modest amount.
You can also look at things such as TIS or SecureID: these are more hard-core, since they're hardware token-based authentication schemes, and generally require custom software (though SSH supports TIS/SecureKey).
As a last resort, you might investigate VPN solutions, since, while they're not PKI in a true sense, they can provide network validation. S/WAN for Linux is a good, free thing here, and you might look at an IPSec implimentation, too.
I'm assuming that your comments relate to my proposals, not the stuff regarding QT/KDE. Also, those were proposals, not statements of where things currently stand.
I'm not so sure that dynamic linking would be seen in a manner that you describe. Linking can be viewed as a manner via which two independent programs communicate. After all, a function call to a library can be seen in a manner very similar to RPC or CORBA calls. Linking doesn't have to mean that the library is part of the app, EVEN IF THE APP IS STATICALLY LINKED (since it can be argued that static linking is for convenience, and nothing more).
In a similar manner, I would view header code in the executable as an artifact of the mechanism of compiling, not a fundamental aspect of the nature of the program. Logically, they are seperate entities. Of course, once you distribute a compiled binary, you must comply with the license terms for each of the components, but we should be able to treat the components seperately.
Thus, I should be able to compile a GPL program that uses a QPL library, an X11 library, and a proprietary (say, patent-protected (eg. RSA)) library. Now, since the program is GPLed, I am required to give away the executable and the GPL's program source (including redistribution rights to both), but I could distribute the QPL library and X11 library in a manner which followed their licenses, and may not have to give away the proprietary lib. This is how things should work, not necessary how they do.
Yes, this does look alot like the model used in the MPL. Though the MPL still treats everything a part of the base program, which is erroneous in my view. I honestly can't understand how we currently can hold two seperate, conflicting views right now: that the license of a program can treat a libary as integral portion of the program, and yet that we can somehow license libaries seperately. Holding the two views is self-contradictory.
Honestly, I think we would solve 90% of our licensing conflicts, lose alot of the ill-feelings between the various camps of the OpenSource movement, and at the same time promote the free sharing of source code if we would stop treating libraries as a part of a program, and not as the individual entities they should be.
Ok, I don't have independent verification of this, but from my talks with several of the big bandwidth providers, and others, there is an interesting problem about providing access for European consumers....
Logically, it would seem to make sense to open a UK (or German, or French) farm to serve EC people, but it turns out this isn't necessarily the case.
The problem seems to be the peering arrangements in the EC are bad-to-non-existant. As far as response time goes, this seems to be the priority of EC network providers:
traffic to their own customers
traffic back to the US backbone folks
traffic to other providers in the EC.
I've heard that the last is considerably below the other two. So the predicament becomes that opening a datacenter in the EC really only buys you better connectivity to people who are directly connected to that datacenter. Oops.
What alot of people have recommended to me is this: Open a datacenter first on the US West coast, then on the US East Coast. The Westie will serve Asia and most of the US, while the Eastie will cover the Eastern seaboard and the E.C. Only after you've done that should you look at putting a datacenter into the E.C., and then consider which PROVIDER (not which Country) has the most demand on it.
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
This is the so-called "system library" exception. Of course, what is a system library? It's a library that comes with the standard distribution (according to the GPL)...
Distributing GPL applications (including KDE) that are dynamically linked to QT is perfectly OK in distributions that include QT as a part of the base OS. RedHat, Suse, Mandrake, TurboLinux, and virtually all distros except Debian include it. Debian does not, as QT is non-free software, and thus does not fit within their philosophy.
Fine for Debian. They hold to their ideals, and that's what they view important. It's hypocritical of them to accuse TT of not bending to their will to change the QT license, though. That's the license, and if it doesn't change, well, there are consequences for Debian users. There's no free lunch, folks.
KDE on the otherhand, needs to be voicing the restrictions that using the QT requires of end-users: that is, KDE should be distributing apps that are dynamically-linked with QT, and also should not be including QT as part of the default install. This is something that the end-user needs to be aware of when choosing to use/not-use KDE.
This leads back to the system-library exemption clause in the GPL: this is totally bogus, since a system library is so ill-defined that I could make anything a system library. Honestly, this clause is so vague that I can ignore the GPL for huge chunks of my code if I just make them into a library (and call it a "system library"), since what is "normally distributed"? And exactly what is a "major component"?
This all leads to my biggest bitch about Licenses in the OpenSource movement in general: somehow, the concept that a standalone library is part of a finished app needs to change. The whole point of dynamic libraries is that the same codebase is shared between multiple apps (well, not the whole point, but one of the major benies...).
We should move towards the following standard:
Respect the license the original code was released under. If you don't like it, don't use the code, and quit bitching about the entity that released the code. If it claims that it's something it's not (like GPL-compatible, OpenSource-compatible, et al), then you can complain about truth-in-advertising, but otherwise, keep the trap shut.
As a correlarry to #1, release all your mods to the original code under the original license. This is merely a show of respect for the originator.
Standalone libraries are not automatically part of the program. They should have their own license. Of course, mods to the original code for accessing the libraries should follow the original code's license. However, why shouldn't a library receive the same consideration that calling an external program (via system() or whatever) currently receives? That library doesn't "belong" to this program any more than an external program belongs to it.
The distinction between static and dynamic linking needs to be erased. This is really a correlarry to #3, the recognition that libraries are a seperately licensable entity.
Actually, it very much does matter for freedom of press.
However, IIRC, in the P.A. tapes case, the ruling was such that the publisher (the video-tape distributor) had a very reasonable belief that tapes were authentically owned by the person who sold them. Of course, the person who stole the tapes in the first place is still civilly liable for that.
This is the key in cases like that - all the publisher has to do is prove that a reasonable person would believe that the source was providing information that wasn't illegally obtained. And the courts have given fairly wide lattitude on this issue (that is, they've erred on the side of the press).
I can deny someone freedom of speech because the exercise of it removes protections provided for in other parts of the Constitution, and it has been deemed that the harm that the exercise of the 1st Amendment is greater than the benefit it provides.
Nothing is absolute.
The cannonical battlefield these days in the 1st Amendment is around Privacy. This is a 1st vs. 4th Amendment battle, and we as a society are in the middle of determining which is more important to us.
Not to flame you, but this isn't a black-and-white world. People who try to make it so, even for idealistic reasons, usually (if not always) cause far more harm than good. This is my major bone to pick with the ACLU. While it's really good to have someone championing the cause of the 1st Amendment (and also the disadvantaged of society), they generally fail to take into account the societial impact of their ideals.
By placing the 1st Amendment as some sort of "holy word", people do it a great disservice. It is a key to our society's wellbeing, but there are many other blocks in the building, and destroying others simply to maintain the supremecy of the 1st is ill-advised, ill-considered, and a detrement to us all.
Note: IANAL, and this information comes from talking with several IP and publishing lawyers. It applies only inside the USA.
Newspapers (and others) cannot publish anything they receieve. Legally, a publisher is responsible for checking the validity of the source, and cannot hide behind the "oh, well, my such-and-such source said so" shield.
Publishers (and reporters, too) have the following responsibilities when receiving information from a source:
Is the publisher coercing the source to break a contract/law when revealing the information?
Would a reasonable person know that the information was obtained illegally?
Is the jist of the information substatiated through another source?
By publishing the information, are you maliciously and willfully damaging another entity? As a correlarry, would a reasonable person decide that you released the information without a proper validity check?
Under number 1 and 2, the publisher is criminally liable - instance number 1 is a felony in most places, 2 is a misdemenor. Essentially, in the first you are actually committing a crime, and the second you are an accessory-after-the-fact.
Instance 3 and 4 fall into civil areas (as can 1, in addition to criminal), and generally are covered in Libel and Slander laws.
Trade secrets that are obtained by a third party, who then illegally reveals them to a publisher, which publishes them, are most certainly covered by #2. However, the sticking point is as always the possibility that the publisher can make a case that it reasonably believed that the information was obtained by the third party legally. The previous brouhah here over the MS Kerberos Spec is a good case for the latter - there is a considerable case for the publisher believing that the poster (an AC) could have bypassed the legalities requiring non-disclosure, and thus, could legally post the article.
Indeed, that was my point. I am very much aware of RMS standpoints on this - I've discussed it with him. I'm also very aware of the GNU literature. Please don't assume otherwise.
As I stated, and you quoted, RMS very much is against the control of ideas. That's what I was talking about. IDEAS, not code. He's all for the free exchange and non-ownership of ideas.
The GPL is a piece of legalism used to protect the concrete expression of ideas (that is, source code). It has nothing to do with the ideas itself. The only reason it exists is that currently, the concrete expression of ideas is controllable. The GPL is an attempt to end-run around this, for a reasonable social cause. And, as such, it's solely focused on code, not ideas. Nothing in the GPL, the GNU Manifesto, or otherwise indicates that RMS believes in any control or restriction of ideas (even the so-called "good" restrictions of the GPL w/r/t enabling free code). By attempting to control the use of his ideas, RMS would be hypocritical in the extreme, which I can definately say he's not. By controlling the use of the expression of his ideas (the code), he's actually attempting to move people in a direction where ideas currently sit: complete non-control.
The GPL (and GNU) are all about protecting the freedom of implementation, don't deal at all with design.
Anyhow, this is all rhetorical. You can't own an idea ( funky business-method patents aside ). So there's nothing preventing you from sharing them with others, and gleening what knowledge you can from elsewhere.
And, if you read my post, I say explicity point out that stealing code is verboten.
Please, take a couple minutes to think before hitting the Reply button. I find that usually helps me stop from putting my foot in my mouth.
All the legalism aside, and contrary to other poster's opinions, I belive that the spirit of the GPL is to insure that ideas are free. I don't think that even in a grouchy mood RSM would insist that you must "free" your own ideas because you like his. And, anyhow, just because you write proprietary code, there isn't any reason why you can't share your idea with someone else (unenforcable NDAs and ill-advised patents notwithstanding...), so I think the proper way to "honor" the GPL in this case is to talk about how you solved the problem with others. Share the ideas.
In essence, that's what you're looking for: ideas. You want to see how other people have solved a problem that is important to you. GPL'd software is intended to be a great bank of knowledge - use it.
Now, of course, is the tricky part - writing your own project. My suggestion to avoid lots of problems is this:
Designate a "learning" period. Go read lots of GPL code. Find OpenSource code - read it. Do a web search. Whatever. Consider this your information gathering phase.
Putz around with alot of the code you've found. Tweak it. Do little test runs to see how it works, and how you can modify it to do stuff. In general, learn the ideas and concepts and then practice.
Next, throw out your test programs. That's right - get rid of them. Also, I suggest you get rid of the initial code (GPL or otherwise) that you used to learn from. By doing this, it eliminates the temptations to "cheat" and use code from places you're not allowed to. Also, it makes it alot easier to insure that you really understand stuff.
Now, sit down and design your approach. Write it all down, and preferably, print it out (or otherwise make a hard-copy of it). If you're paranoid, go get it timestamped/notorized. This is an excellent way to insure that you're "Clean-Rooming" the implimentation, and, incidentally, also insures that you think through what you're doing.
Last step: code the implementation from your Specs.
I heartily agree with the preceeding posters' recommendations. They all have very valid points, and I suggest you listen to them.
A couple more on my own:
As was stated before, being a true Software Engineer is less about coding, and more about project management, interpersonal relationships, human management, and other fuzzy details. For you, I wouldn't worry; the best way to pick up on these skills is by working in the industry, and observing your superiors. Some will be good, some horrible, and a few amazing. I've gotten lucky and have worked with more than my share of amazing.
What your question really is asking has to do with software design. I agree that this is critically important - a huge amount of what the industry deals with today is shoddy design. Besides doing small projects yourself (as a previous poster suggested), I would look at some other people's code. I suggest the GNU code, in particular. Several packages have been long stable (such as bison), and are really solidly designed. I would look at some of the pre-1.0 Gnome code (it's still floating around) to see some messy stuff (I like Gnome, but hey, it was really early code). Look at how they put the stuff together, and try to improve it (not functionality-wise, but style-wise). Learn by doing.
My final recommendation are several books I've found really helpful:
Structure and Interpretation of Computer Programs (Abelson and Sussman) - this is the intro CS book at MIT. While it concentrates alot on programming methodology (and uses Scheme), it's really a great refresher on stuff.
Abstraction and Specification in Program Development (Liskov and Guttag) - this is the core Software Engineering book at MIT. It's great - covers all the random things you should be thinking of when starting a project. It uses CLU as a language, but the concepts translate directly to other languages. Unfortunately, it's out of print, but you can still pick up copies all around. The replacement for it (Program Development in Java: Abstraction, Specification, and Object-Oriented Design (liskov)) won't be out for another couple of months.
Finally, read Introduction to Algorithms (cormen, leiserson, rivest) - this is both a great book on all sorts of algorithmic methods, but a good software design book as well. It's used as the core CS algorithms book at a large number of colleges (like, maybe in 40% of all CS people I know used it in college).
The books above can be found at the MITPress, including how to get out-of-print stuff.
Handouts and other stuff for classes at MIT that used to above books (6.001, 6.170, and 6.046J) can be found from the MIT Course Catalog here - you might explore a couple of the other 6.0xx series (ie, look at the web pages associated with them) as they have useful stuff there too.
That was an over-harsh summary. Yes, corporations do represent the majority of ICANN membership, and this does skew things towards the corporation point. However, remember that board members are not supposed to be flunkies - they actually have to know something about the Internet. Look at the IETF - the vast majority of people involved in the IETF are sponsored by their companies to work on a group.
That said, I think we certainly do need to press for more representation, and we certainly need to use what we have.
The Nominating Committee needs to be done away with. All nominations should come from the Community-at-large. We'll have to see if the 10% nomination limit is over-restrictive (I suspect it is, and sometime like a 1% of all elegible voters would probably be better).
Remember, you can only vote for one ICANN member - the one covering your region. However, you can help NOMINATE someone from another region.
That said, I'm going to explore a Self-Nomination run. About the only way I could conceive of something like this working is to get the backing of some large/.-like forum that has a wide reach. USENIX, IEEE, or the ACM, maybe, too.
Just out of curiosity, would any of you vote for me (seriously)?
OK, I've been living out here in Silicon Valley for about 20 months now, and I've previously lived over large sections of both Boston MA, Pittsburgh PA, and Washington, DC.
A couple of things people need to realize about the Bay Area: physically, there are six generally distinct regions out here (San Francisio proper, Marin County (north of SF), Oakland/Berkeley, the East Bay, the Peninsula, and San Jose). I'm going to be making general statements that don't completely categorize the entire areas, but are mostly true.
Jobs are concentrated in San Jose and the Peninsula. About 75% of all tech jobs are in these places. San Francisco has about 10%, and the East Bay has about 10%. There are relatively few jobs in Marin or Oakland/Berkeley.
Commuting from Marin County to anything other than San Francisco or Oakland is ludicrous. There are major traffic choke points that simply won't go away, and you can't get around. Commuting from Oakland or SanFran to San Jose is nasty (IMHO not doable), and commuting from East Bay (or further east, like Walnut Creek) to the Peninsula is really harsh.
Rent is quite high on the Peninsula and San Fran. It usually runs $1200-1500 for a 1br, and around $2000 for a 2br. These are prices for decent places. Rent in San Jose is less, as is East Bay (up to 25% less, as a rule) for about the same thing.
Housing on the Peninsula is atrocious. Don't let anyone else tell you otherwise. 30-year-old, not-well-maintained houses go for not less than $300k and up to $700k. None of these would be in "exclusive" neighborhoods - this is middle-class housing in average places. A nice house in a good neighborhood (say a chunk of San Mateo) runs $1.2million easy.
Housing in San Francisco is impossible. 1000sq ft lofts run $400k. Forget anything else. Condos start in the $600k-range.
East Bay still has decent housing prices, depending on where you look. Middle-class housing runs $200-400k.
Marin has a variety of housing, depending on where you live. It can be cheap ($150k) to very expensive ($1.5m) for the same house, depending on which community you live in.
Berkeley is still a college town, and you compete with the students for housing. My advice is: don't. Oakland and San Jose are still industrialized, with suburbs. The suburbs of San Jose generally have housing similar to the Peninsula.
Commuting can be really harsh, since there are several large choke points that most traffic must pass through to get from one of the areas to another. Commuting within your area is pretty decent.
Public transporation is really only usable within urban San Jose, and within/between SanFran/Oakland (due to BART). Public transportaion in the other areas is a joke.
Gas is the most expensive in the US (running $1.70 nowdays), but the rest of the cost of living is about the same as other major cities.
Zoning laws are preventing high-density buildings, and lower-income (ie, those without a tech job) people are starting to flee. Public transportation isn't going to get any better, and there is no more room for roads. Unless something changes drastically, Silicon Valley will choke to death in about 5-10 years.
Fundamentally, the only real reason to live here anymore is that you can hope to cash in on an IPO. Moving out here to work in a regular tech job is not a good decision - you should look elsewhere.
This is not meant to be a compete downer. I love my friends here, and there are major perks. But this is a hard-core Boom Town. Adjust accordingly.
I agree, that the East Bay is alot cheaper, and not anywhere near as bad as the snobbish over here on the Peninsula claim it is (I'm in Mountain View). However, there is one HUGE drawback to living in the East Bay:
The Bridges.
If you telecommute all the time, or work over on the eastern side, I'd live over there in a heartbeat. However, the sad fact is that about 80% of all work is located somewhere between San Fran and San Jose, over here on the Peninsula.
I'm not even going to think about driving across the bridges to get to the peninsula. There are EXACTLY TWO BRIDGES (with a total of 5 lanes of traffic between them (each way)) to get from East Bay to the Peninsula. I work in Foster City, and have a view out my window of the San Mateo Bridge. Let me tell you, it moves at about 10 mph for 2 hours each night, and that bridge is at least 5 miles long.
Sadly, the East Bay isn't really practical for alot of us who work mid-Peninsula. If you work in San Jose, yes, but not Sunnyvale-Burlingame.
Actually, this is a reply to the two previous responses...
Yes, I am fully aware of the great clustering & HA setup for Tru64 - I've worked with it extensively. The clustering tools require the Tru64 kernel, which is why I suggested that they might explore using the Tru64 kernel as a drop-in replacement for the Linux kernel. You'd be able to use the clustering software already written for Tru64, and get the neat features it provides.
Also, porting glibc to Tru64 doesn't give you Linux compatibility. It's already ported to Tru64. Compatibility has alot more to do with things other than the C library.
The problem for Compaq is that maintaining the Tru64 system as a whole is alot of work. And I mean ALOT of work. If they could concentrate on their kernel and the few places they make really excellent add-ons (the HA stuff being the primary), they could save alot of $$. Pawn off all the non-interesting userland tools to the OpenSoftware folks.
Also, Tru64 doesn't make alot of sense on the Alpha workstations - a small improvement in Linux gives you the performance of Tru64, and you're not going to be using all the neat features of Tru64 on an AlphaStation anyway.
Like I said, but perhaps not clear enough, Tru64 make alot of sense on the NonStop stuff right now. It also make sense on the high-end AlphaServers. It makes no sense on the AlphaStations, and I think Compaq could save themselves alot of cash, and make alot more by concentrating on making a hybrid Linux/Tru64 system for everything but the NonStop stuff.
Look at what SGI is doing - Compaq could learn from them.
I've always wondered about the road Compaq was going to take w/r/t Tru64. Earlier, they had announced that the NonStop-series (the old Tandem boxes) were going to use Alphas, and the general assumption was that a modified Tru64 would replace the current custom UNIX on them.
The reasons to continue to support Tru64 on the AlphaServer series is becoming less and less - a vast majority of the neat Tru64 features are (or will be by Q4/2000) available on Linux. Performance is still in Tru64's favor, but that has mostly to do with the optimizing compiler and assembly-tuned system libraries.
In truth, I can easily see Compaq going the route SGI is going: abandon their in-house UNIX brand over a couple of years in favor of Linux, while insuring that there is a Tru64-compatibility layer in Linux.
One thing I'd be interested in seeing is if Compaq would release the Tru64 kernel as OpenSource, and try to build a complimentary kernel system. That is, modify the Tru64 kernel a bit so that it could be a drop-in replacement for the Linux kernel (so RMS could call it a Tru/GNU system!:-). I am aware that this would cause some problems (obviously, no Linux driver would work in a Tru64-based kernel), but I can't see that userland programs would object much at all. Compaq could get all the advantages of having complete Linux-compatible userland programs, and yet, we'd get a kernel that could take advantage of all of Compaq's nice HA and clustering stuff, which are considerably better than Linux (as in MUCH, MUCH better).
Honestly, as a previous poster pointed out, I can't see Compaq opening up their compiler technology right now (it's a major advantage against Intel. Who know what bubbles in the minds of Compaq Management? I certainly don't.
First off, let me preface this by two caveauts: (1) I am a natural US citizen, so all the following is through talking with friends who've gone (or are going through) the visa thing, and (2) my experiences are relative only to the Computer Industry in the Boston, MA and Silicon Valley area.
The biggest advice that I can give to someone looking for a US-job is this: come here first. DON'T go through a foreign recruiting agency - most of my friends have had nothing but bad things to say about them. By coming to the US, you get three critical things:
Exposure to the culture. Can you stomach the way the US does things? (and remember, you're going to live here for years, so you better like the fucked up way we do stuff,) Can you relate to the people? - Americans are very different from any other culture.
Economics - while you're here, look at the various aspects of what it costs to live in the area of the US you're interested in: housing (both buying a house and renting a flat), food, transportation (what type of commute, is there public transportation, etc). Most likely, the economics of the US are considerably different from where you're from.
A true view of the job market. Go talk to some of the recruiting firms here, and ask for an overview of both the available jobs for your field, and then what companies have specifically stated they will support (or will specifically NOT support) foreign workers.
Coming to the US is fairly easy - one of the best ways is to get admitted to a US university for a year - you get a student visa, and you generally have 90 days afterwards to find a job before it expires (not to mention the time you're supposed to be in school). Student Visas from virtually any 1st-world country are a no-brainer. Likewise, if you don't want to do that, getting a 90-day tourist visa is a no-brainer, and tourist visas of up to a full year aren't hard to get. Remember, neither a student nor a tourist visa allows you to legally work in the USA.
On to the second part: working for a US company when you're a foreigner. A previous poster pointed out that foreigners are to a certain extent perceived as "cheap" labor. While I do think that this is a problem, this is more a function of how you sell yourself at a job interview. If you have in-demand skills, and, more importantly, have very good English communication skills, companies aren't going to treat you any different from a US worker. Finding qualified people is very hard for many positions, so any qualified applicant is going to be zealously sought-after. Do be aware that getting an H-1B visa costs the company extra, so they might offer you slightly less than a US-worker, but I think this is a fair trade off. Now, if you see that they're offering you only 2/3 what equivalent positions are advertised at, they're trying to take advantage of you.
Do rememeber than working on an H-1B visa is a temporary thing. You're not elligible for a permanent resident visa (Green card). Technically, you can't stay more than 5 years (though, this tends to be ill-enforced). Likewise, you're not supposed to be able to apply for a different type of visa once you have an H-1B, but I haven't heard of anyone ever having problems with that (the INS doesn't seem to really care). Also, H-1Bs require that you be employed by a sponsoring company at all times (actually, I think you have something like 30 days from quiting one company to getting hired by another) - this can be a problem, as you might feel required to stay at a company since they sponsor you. This is where many foreign workers get into trouble - they get hitched to a company that doesn't treat them well, then feel trapped, since they don't have the confidence to find another job. Look at the amount of work in your field, and judge how easy it would be to switch jobs (the 30-day window isn't enforced much, but I'd be leery of pushing it too much).
You should talk to your local US Embassy or Consulate about the various types of available visas, and what the restrictions are for each. Pay close attention to the industries that certain visas allow you to work in, travel restrictions (can you come and go freely to your country or not?), and to whether the visa is tied to a sponsoring company or if it is granted to you (and thus, floats with you as you move employers).
Send me a note if you're interested in more info, and I'll see what I can help you with.
yes, even the smallest flywheel has gyroscopic precession problems. Yes there is a danger that they might shatter and shoot out lots of nasty fragments. Then again, your typical battery can spontaneously burst into flames, spew acid all over the place, and generally trash your surroundings at the drop of the hat. I don't see too many peole complaining about those problems.
The precession problem with flywheels can be almost completely negated by using two counter-rotating flywheels. yes, I am aware that there will be some problems with movement along the Z-axis, but this is managable in instances where there is little Z-movement (such as cars).
Furthermore, the heat problem is significantly reduces (in fact, almost eliminated) if the flywheel is contained in a sealed vacuum shell. For safety's sake, making this shell from something like kevlar would reduce the small risk associated with flywheel failures at high speed.
The biggest problem with using flywheels is that there has to be some sort of electric motor - that is, something that can change mechanical movement to electrical energy. In items like cars and UPSes, this isn't much of a problem. In your laptop (and similar compact places) this is definately a stumbling block. I wouldn't look for flywheels in laptops anytime soon.
I expect to see flywheels in electric cars in the near future, since they offer alot of advantages over a most batteries: lighter weight, a very high energy capacity, ability to deliver large amounts of current quickly (something most non-lead-acid batteries can't do), and virtually no maintenance.
Honestly, I can't wait for the hybrid car to come along: small, constant RPM gasoline engine, electric generator, and flywheel. You have a lead-acid to start the whole thing, and store any excess energy in the flywheel. Cool!
I read the whole article, and while it raises some worthwhile points (other than the random gun control thing - what has that got to do with anything?), I think Meyer has missed the fundamental link between Ethics and OpenSoftware (I'm going to reserve FreeSoftware for GPL'd stuff).
Under the harsh light of analysis, Ethics are a set of socially pragmatic guidlines. They aren't rules (some are laws, some aren't). Instead, Ethics are social conventions that allow a given society to remain cohesive and functional. That's the extent of them. They aren't "God-given" or some other divinity-enforced, but rather religion has been used as a method of enforcement of Ethics for millenia. Something becomes Ethical in a society when a large majority of the population sees that such a rule/value is beneficial to the society. That's why Ethics change - it was highly ethical to own slaves for virtually the entire course of human history until the 19th Century, when most cultures decided that it suddenly was no longer worth the problems it caused. We now view slavery as unethical.
So how does this relate to OpenSoftware? OpenSoftware is all about pragmatism. There are differing degrees of how pragmatic one wants to be (just as there were degrees of zeal in the abolitionist movement), but the fundamental reason driving the OpenSoftware movement is pragmatism: OpenSoftware provides benefits and advantages to both the developers and users that are deemed to outweigh the disadvantages. In addition, the general viewpoint has come to the pragmatic conclusion that, for most items, closed software is inferior in features to OpenSoftware (by features, I mean advantages to the user/developer population, not bells-and-whistles).
Now, the Ethical thing here is that we have come to realize that a promoter of OpenSoftware is Good. Thus, OpenSoftware developers have high Ethical status, which is a social advantage.
The main point to all this is that OpenSoftware and Proprietary Software aren't opposed - they can co-exists. In fact, given the relative advantages of each, they both should occupy their market niche, and we should recognize that (and criticize those who engage in extremism for no socially-justifiable reason).
This "my-shit-is-better-than-your-shit" absolutism rhetoric is exactly what is unEthical. Ethics is pragmatism, practiced on a cultural level. When we (as a society) decide that one is a clear wholesale detriment to society, then it will generally be deemed unEthical. As long as both methods have defined uses (ie. markets) where their overall contributions outweigh their overall liabilities, they both should survive, heated rhetoric aside.
OpenSoftware is more about questioning the fundamental assumptions that have ruled the Software Industry than about some new large-scale societal revolution. Both sides would be well-advised to remember that.
Not to toot my own horn here, but I both do currently work for, and have in the immediate past worked for, companies that are potentially hugely affected by the DMCA.
I'm also responsible for our possible compliance thereunder. It Sucks. It makes my job a massive bitch, costs my company a boatload of cash and time to comply with, and generally makes my life miserable.
So, you bet I'm going to be there to let them know it's not just private citizen that are sick of the DMCA. It sucks hard for businesses, too - look at all the budding e-whatever, and I-whatever companies that are getting killed by the hired guns of the big media companies.
If you want a ride Thursday, give me a call. I work in Foster City, so I'll be heading down 101 sometime around 11:30.
This is what the industry calls dedicated RAM drives. Essentially, they tend to be 5.25" full-height devices that have a SCSI-controller on the back (some of the newer ones have FibreChannel), and appear as a normal SCSI drive (just with 1000x the performance).
If you peek inside the device, it's filled with a little bit of circuitry, and SIMM or DIMM slots, and a small rechargable battery. Not rocket science here.
The problem is that they sell to a niche market, and thus you're looking at about $10/MB or more. Actually, I think more in the range of $50-100/MB. It's totally outrageous.
8GB isn't alot of RAM - I'd look into getting a good-sized Sun (maybe an E3000) or HP (like an L2000) or other UNIX box. Most of these class machines run between $100k and $300k for a 4-way config, and you get so much more for your money.
Given the current pricing of solid-state drives, they make almost no sense for anyone. Just get a bigger machine that can handle the amount of RAM you need for the DB. The cost of a 4-way E3000 w/ 8GB of RAM is somewhere around $200k, which is almost certainly less than what you'd pay for 8 1GB solid-state drives.
Industry pricing is stupid, isn't it?
-Erik
PS - this isn't unique. Look at what people want for a dedicated SSL hardware accellerator. With CPUs so cheap, it's hard to justify paying $5k for a PCI card that has the same performance as a 700Mhz P3...
I'm a gun-control advocate. However, I don't see how anything we do currently improves anything, so I'm in favor of giving up on gun-control completely.
That's right. Allow any Tom, Dick, Harry, or Jane to go down to the corner store, and buy themselves a full-auto AK-47 if they want. No background check, no license, just hand over the $300 and Presto! one nice assault rifle.
However, it should be illegal to commercially sell ammo. That's right. You can sell those nice little "do-it-yourself-by-hand" ammo loaders, but no big automated super-industrialized ones, and companies are forbidden to sell manufactured ammo.
The Constitution makes no mention of the right to unlimited ammo. Nope. You want rights - you can have the same ones that the Minutemen had - make your own damn ammo, you lazy Americans!:-)
I'd like to see how long we had a gun problem around here when you can't make 1,000 rounds of ammo for your nice HK MP-3, and you jam every 5th round since you're too hopped up on drugs to run the ammo-loader properly...
Slashdot Mirror
...I saw some of the massive ignorant egos strutting around, and couldn't just let it pass. So I post.
:-)
Look, people, Sun will never OpenSource Solaris. I do take issue with them (in particular, the marketing 'droids) initially toutting Solaris as being OpenSourced, but they have backed off this - you will note that everything in their current campaign talks about a "Free Source License" and similar terms. Yes, some people may confuse it with the Free Software movement, but face it people, 99% of people associate the word free with cost (as in beer), and not with libre (as in GNU).
Also, look at what Sun is trying to target. Essentially, they make money on hardware and services for Solaris, and no money on the OS (even when they charge for it, it's insignificant in the scheme of things). By using the SCSL, there are the following benefits:
As a side note, please note a couple of things about distributing mods to Solaris 8 (and using Solaris code):
Yes, the Free Solaris Source Code program isn't an OpenSource movement by Sun. It has it's uses, and for that I'm happy. It definitely is limited, but for those target markets, it's a Good Thing. Maybe someday they truly will Open Source Solaris, but only when Sun sees that the advantages for Sun to Open Source outweigh the benefits they get from SCSL.
-Erik
You're making a file server, and by far you're biggest problem is going to be I/O bottlenecks (disk & network), NOT CPU. In fact, I can keep a 100Mbit connection fully flooded with SMB traffic with a lowly Dual PPro200 system. So the second CPU isn't necessary at all. Here are my recommendations (and I've done this before):
If the machine is doing pure Smaba serving, and you are using external PDCs, get the lowest-speed CPU you can (which will probably mean at least a 500Mhz one). It will be more than sufficient. Use the money for your disk subsystem.
If you want to do something like virus scanning, or PDC work, or even DNS serving, look into a better CPU, especially if your going to be doing Mail on the box (which is a CPU hog). In general, though, I think you'd be better off with sticking to a limited-function box and 1 CPU.
Product Plug: I like Compaq Proliants. They're very Linux-friendly, and they have the nice extras you want in a server. Here's a suggested config:
That runs $11k direct from Compaq (figure you get it cheaper from a reseller). You can knock off $2k if you use 7200RPM drives.
Look for something similar. Having a dual-capable MB is nice, just in case you decide to add crap to the machine later (or re-purpose it).
Best of Luck.
-Erik
Honestly, I can't see it being any more risky to leave a computer on unattended (which is what you're really asking) than leaving the TV set on.
The big thing here is common sense. A computer is an electrical device (indeed, one that consumes a fair amount of power). You should treat it as such. By far your greatest hazzard is a short-circuit that sparks, which can result in a fire.
All in all, common sense. One thing here: if you can possibly arrange it, put the computer in a room that doesn't have carpeting - and definately avoid rugs. It cuts down on dust and crap, and is slightly safer (linoleum, tile, concrete, or even a wood floor is much less likely to catch fire from random sparks).
Most of this advices goes for all computer-related equipment (hubs, telco stuff, UPSes...), though the low-power and general safety of small networking gear makes it possible to safely stow in closets (but do try not to stack clothes/inflammibles on it) - I usually recommend putting it in something similar to a metal milk crate.
-Erik
Fundamentally, the problem you describe is this:
How do I trust a user is who they say they are?
If you can count on that, then you have any number of access/content control mechanisms. This is exactly what PKI (Public Key Infrastructure) addresses.
Fundamentally, you don't want to validate the machine, you're interested in the user. So forget network id, et al.
As others have pointed out, the obvious solution is Kerberos, from MIT. It was specifically designed to solve the problem you have. However, you have to build kerberos into your application, so it's not simple, and neither is the setup.
The second most popular solution are Personal Digital Certificates (NOT SSL Certificates). These are tied into Web Server authentication (for the most part), but can be used as a generic authentication mechanism. Depending on what you want, they can be relatively cheap and uncomplicated, or it can get pretty hairy. Look at Thawte for a decent example - also, check out the iPlanet Certificate Server for some relevant info. Honestly, this is probably the easiest way to do what you want, IF you can do a web-based service. It won't be free, but if you scrape around, you can probably get it in place for a modest amount.
You can also look at things such as TIS or SecureID: these are more hard-core, since they're hardware token-based authentication schemes, and generally require custom software (though SSH supports TIS/SecureKey).
As a last resort, you might investigate VPN solutions, since, while they're not PKI in a true sense, they can provide network validation. S/WAN for Linux is a good, free thing here, and you might look at an IPSec implimentation, too.
Best of Luck.
-Erik
Bruce,
I'm assuming that your comments relate to my proposals, not the stuff regarding QT/KDE. Also, those were proposals, not statements of where things currently stand.
I'm not so sure that dynamic linking would be seen in a manner that you describe. Linking can be viewed as a manner via which two independent programs communicate. After all, a function call to a library can be seen in a manner very similar to RPC or CORBA calls. Linking doesn't have to mean that the library is part of the app, EVEN IF THE APP IS STATICALLY LINKED (since it can be argued that static linking is for convenience, and nothing more).
In a similar manner, I would view header code in the executable as an artifact of the mechanism of compiling, not a fundamental aspect of the nature of the program. Logically, they are seperate entities. Of course, once you distribute a compiled binary, you must comply with the license terms for each of the components, but we should be able to treat the components seperately.
Thus, I should be able to compile a GPL program that uses a QPL library, an X11 library, and a proprietary (say, patent-protected (eg. RSA)) library. Now, since the program is GPLed, I am required to give away the executable and the GPL's program source (including redistribution rights to both), but I could distribute the QPL library and X11 library in a manner which followed their licenses, and may not have to give away the proprietary lib. This is how things should work, not necessary how they do.
Yes, this does look alot like the model used in the MPL. Though the MPL still treats everything a part of the base program, which is erroneous in my view. I honestly can't understand how we currently can hold two seperate, conflicting views right now: that the license of a program can treat a libary as integral portion of the program, and yet that we can somehow license libaries seperately. Holding the two views is self-contradictory.
Honestly, I think we would solve 90% of our licensing conflicts, lose alot of the ill-feelings between the various camps of the OpenSource movement, and at the same time promote the free sharing of source code if we would stop treating libraries as a part of a program, and not as the individual entities they should be.
-Erik
Ok, I don't have independent verification of this, but from my talks with several of the big bandwidth providers, and others, there is an interesting problem about providing access for European consumers....
Logically, it would seem to make sense to open a UK (or German, or French) farm to serve EC people, but it turns out this isn't necessarily the case.
The problem seems to be the peering arrangements in the EC are bad-to-non-existant. As far as response time goes, this seems to be the priority of EC network providers:
I've heard that the last is considerably below the other two. So the predicament becomes that opening a datacenter in the EC really only buys you better connectivity to people who are directly connected to that datacenter. Oops.
What alot of people have recommended to me is this: Open a datacenter first on the US West coast, then on the US East Coast. The Westie will serve Asia and most of the US, while the Eastie will cover the Eastern seaboard and the E.C. Only after you've done that should you look at putting a datacenter into the E.C., and then consider which PROVIDER (not which Country) has the most demand on it.
Stuff is funky, isn't it?
-Erik
And I quote (GPL, version 2, section 3):
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
This is the so-called "system library" exception. Of course, what is a system library? It's a library that comes with the standard distribution (according to the GPL)...
Distributing GPL applications (including KDE) that are dynamically linked to QT is perfectly OK in distributions that include QT as a part of the base OS. RedHat, Suse, Mandrake, TurboLinux, and virtually all distros except Debian include it. Debian does not, as QT is non-free software, and thus does not fit within their philosophy.
Fine for Debian. They hold to their ideals, and that's what they view important. It's hypocritical of them to accuse TT of not bending to their will to change the QT license, though. That's the license, and if it doesn't change, well, there are consequences for Debian users. There's no free lunch, folks.
KDE on the otherhand, needs to be voicing the restrictions that using the QT requires of end-users: that is, KDE should be distributing apps that are dynamically-linked with QT, and also should not be including QT as part of the default install. This is something that the end-user needs to be aware of when choosing to use/not-use KDE.
This leads back to the system-library exemption clause in the GPL: this is totally bogus, since a system library is so ill-defined that I could make anything a system library. Honestly, this clause is so vague that I can ignore the GPL for huge chunks of my code if I just make them into a library (and call it a "system library"), since what is "normally distributed"? And exactly what is a "major component"?
This all leads to my biggest bitch about Licenses in the OpenSource movement in general: somehow, the concept that a standalone library is part of a finished app needs to change. The whole point of dynamic libraries is that the same codebase is shared between multiple apps (well, not the whole point, but one of the major benies...).
We should move towards the following standard:
-Erik
Actually, it very much does matter for freedom of press.
However, IIRC, in the P.A. tapes case, the ruling was such that the publisher (the video-tape distributor) had a very reasonable belief that tapes were authentically owned by the person who sold them. Of course, the person who stole the tapes in the first place is still civilly liable for that.
This is the key in cases like that - all the publisher has to do is prove that a reasonable person would believe that the source was providing information that wasn't illegally obtained. And the courts have given fairly wide lattitude on this issue (that is, they've erred on the side of the press).
-Erik
I can deny someone freedom of speech because the exercise of it removes protections provided for in other parts of the Constitution, and it has been deemed that the harm that the exercise of the 1st Amendment is greater than the benefit it provides.
Nothing is absolute.
The cannonical battlefield these days in the 1st Amendment is around Privacy. This is a 1st vs. 4th Amendment battle, and we as a society are in the middle of determining which is more important to us.
Not to flame you, but this isn't a black-and-white world. People who try to make it so, even for idealistic reasons, usually (if not always) cause far more harm than good. This is my major bone to pick with the ACLU. While it's really good to have someone championing the cause of the 1st Amendment (and also the disadvantaged of society), they generally fail to take into account the societial impact of their ideals.
By placing the 1st Amendment as some sort of "holy word", people do it a great disservice. It is a key to our society's wellbeing, but there are many other blocks in the building, and destroying others simply to maintain the supremecy of the 1st is ill-advised, ill-considered, and a detrement to us all.
-Erik
Note: IANAL, and this information comes from talking with several IP and publishing lawyers. It applies only inside the USA.
Newspapers (and others) cannot publish anything they receieve. Legally, a publisher is responsible for checking the validity of the source, and cannot hide behind the "oh, well, my such-and-such source said so" shield.
Publishers (and reporters, too) have the following responsibilities when receiving information from a source:
Under number 1 and 2, the publisher is criminally liable - instance number 1 is a felony in most places, 2 is a misdemenor. Essentially, in the first you are actually committing a crime, and the second you are an accessory-after-the-fact.
Instance 3 and 4 fall into civil areas (as can 1, in addition to criminal), and generally are covered in Libel and Slander laws.
Trade secrets that are obtained by a third party, who then illegally reveals them to a publisher, which publishes them, are most certainly covered by #2. However, the sticking point is as always the possibility that the publisher can make a case that it reasonably believed that the information was obtained by the third party legally. The previous brouhah here over the MS Kerberos Spec is a good case for the latter - there is a considerable case for the publisher believing that the poster (an AC) could have bypassed the legalities requiring non-disclosure, and thus, could legally post the article.
Please, folks, two things:
This isn't about censorship
Free Speech is not absolute
-Erik
Indeed, that was my point. I am very much aware of RMS standpoints on this - I've discussed it with him. I'm also very aware of the GNU literature. Please don't assume otherwise.
As I stated, and you quoted, RMS very much is against the control of ideas. That's what I was talking about. IDEAS, not code. He's all for the free exchange and non-ownership of ideas.
The GPL is a piece of legalism used to protect the concrete expression of ideas (that is, source code). It has nothing to do with the ideas itself. The only reason it exists is that currently, the concrete expression of ideas is controllable. The GPL is an attempt to end-run around this, for a reasonable social cause. And, as such, it's solely focused on code, not ideas. Nothing in the GPL, the GNU Manifesto, or otherwise indicates that RMS believes in any control or restriction of ideas (even the so-called "good" restrictions of the GPL w/r/t enabling free code). By attempting to control the use of his ideas, RMS would be hypocritical in the extreme, which I can definately say he's not. By controlling the use of the expression of his ideas (the code), he's actually attempting to move people in a direction where ideas currently sit: complete non-control.
The GPL (and GNU) are all about protecting the freedom of implementation, don't deal at all with design.
Anyhow, this is all rhetorical. You can't own an idea ( funky business-method patents aside ). So there's nothing preventing you from sharing them with others, and gleening what knowledge you can from elsewhere.
And, if you read my post, I say explicity point out that stealing code is verboten.
Please, take a couple minutes to think before hitting the Reply button. I find that usually helps me stop from putting my foot in my mouth.
-Erik
.. Go for It!
All the legalism aside, and contrary to other poster's opinions, I belive that the spirit of the GPL is to insure that ideas are free. I don't think that even in a grouchy mood RSM would insist that you must "free" your own ideas because you like his. And, anyhow, just because you write proprietary code, there isn't any reason why you can't share your idea with someone else (unenforcable NDAs and ill-advised patents notwithstanding...), so I think the proper way to "honor" the GPL in this case is to talk about how you solved the problem with others. Share the ideas.
In essence, that's what you're looking for: ideas. You want to see how other people have solved a problem that is important to you. GPL'd software is intended to be a great bank of knowledge - use it.
Now, of course, is the tricky part - writing your own project. My suggestion to avoid lots of problems is this:
Best of Luck.
-Erik
I heartily agree with the preceeding posters' recommendations. They all have very valid points, and I suggest you listen to them.
A couple more on my own:
The books above can be found at the MITPress, including how to get out-of-print stuff.
Handouts and other stuff for classes at MIT that used to above books (6.001, 6.170, and 6.046J) can be found from the MIT Course Catalog here - you might explore a couple of the other 6.0xx series (ie, look at the web pages associated with them) as they have useful stuff there too.
Best of luck!
-Erik (an MIT dude, if you missed that...)
Michael,
That was an over-harsh summary. Yes, corporations do represent the majority of ICANN membership, and this does skew things towards the corporation point. However, remember that board members are not supposed to be flunkies - they actually have to know something about the Internet. Look at the IETF - the vast majority of people involved in the IETF are sponsored by their companies to work on a group.
That said, I think we certainly do need to press for more representation, and we certainly need to use what we have.
The Nominating Committee needs to be done away with. All nominations should come from the Community-at-large. We'll have to see if the 10% nomination limit is over-restrictive (I suspect it is, and sometime like a 1% of all elegible voters would probably be better).
Remember, you can only vote for one ICANN member - the one covering your region. However, you can help NOMINATE someone from another region.
That said, I'm going to explore a Self-Nomination run. About the only way I could conceive of something like this working is to get the backing of some large /.-like forum that has a wide reach. USENIX, IEEE, or the ACM, maybe, too.
Just out of curiosity, would any of you vote for me (seriously)?
-Erik
OK, I've been living out here in Silicon Valley for about 20 months now, and I've previously lived over large sections of both Boston MA, Pittsburgh PA, and Washington, DC.
A couple of things people need to realize about the Bay Area: physically, there are six generally distinct regions out here (San Francisio proper, Marin County (north of SF), Oakland/Berkeley, the East Bay, the Peninsula, and San Jose). I'm going to be making general statements that don't completely categorize the entire areas, but are mostly true.
Housing in San Francisco is impossible. 1000sq ft lofts run $400k. Forget anything else. Condos start in the $600k-range.
East Bay still has decent housing prices, depending on where you look. Middle-class housing runs $200-400k.
Marin has a variety of housing, depending on where you live. It can be cheap ($150k) to very expensive ($1.5m) for the same house, depending on which community you live in.
Berkeley is still a college town, and you compete with the students for housing. My advice is: don't. Oakland and San Jose are still industrialized, with suburbs. The suburbs of San Jose generally have housing similar to the Peninsula.
Gas is the most expensive in the US (running $1.70 nowdays), but the rest of the cost of living is about the same as other major cities.
Zoning laws are preventing high-density buildings, and lower-income (ie, those without a tech job) people are starting to flee. Public transportation isn't going to get any better, and there is no more room for roads. Unless something changes drastically, Silicon Valley will choke to death in about 5-10 years.
Fundamentally, the only real reason to live here anymore is that you can hope to cash in on an IPO. Moving out here to work in a regular tech job is not a good decision - you should look elsewhere.
This is not meant to be a compete downer. I love my friends here, and there are major perks. But this is a hard-core Boom Town. Adjust accordingly.
-Erik
Bruce,
I agree, that the East Bay is alot cheaper, and not anywhere near as bad as the snobbish over here on the Peninsula claim it is (I'm in Mountain View). However, there is one HUGE drawback to living in the East Bay:
The Bridges.
If you telecommute all the time, or work over on the eastern side, I'd live over there in a heartbeat. However, the sad fact is that about 80% of all work is located somewhere between San Fran and San Jose, over here on the Peninsula.
I'm not even going to think about driving across the bridges to get to the peninsula. There are EXACTLY TWO BRIDGES (with a total of 5 lanes of traffic between them (each way)) to get from East Bay to the Peninsula. I work in Foster City, and have a view out my window of the San Mateo Bridge. Let me tell you, it moves at about 10 mph for 2 hours each night, and that bridge is at least 5 miles long.
Sadly, the East Bay isn't really practical for alot of us who work mid-Peninsula. If you work in San Jose, yes, but not Sunnyvale-Burlingame.
-Erik
Actually, this is a reply to the two previous responses...
Yes, I am fully aware of the great clustering & HA setup for Tru64 - I've worked with it extensively. The clustering tools require the Tru64 kernel, which is why I suggested that they might explore using the Tru64 kernel as a drop-in replacement for the Linux kernel. You'd be able to use the clustering software already written for Tru64, and get the neat features it provides.
Also, porting glibc to Tru64 doesn't give you Linux compatibility. It's already ported to Tru64. Compatibility has alot more to do with things other than the C library.
The problem for Compaq is that maintaining the Tru64 system as a whole is alot of work. And I mean ALOT of work. If they could concentrate on their kernel and the few places they make really excellent add-ons (the HA stuff being the primary), they could save alot of $$. Pawn off all the non-interesting userland tools to the OpenSoftware folks.
Also, Tru64 doesn't make alot of sense on the Alpha workstations - a small improvement in Linux gives you the performance of Tru64, and you're not going to be using all the neat features of Tru64 on an AlphaStation anyway.
Like I said, but perhaps not clear enough, Tru64 make alot of sense on the NonStop stuff right now. It also make sense on the high-end AlphaServers. It makes no sense on the AlphaStations, and I think Compaq could save themselves alot of cash, and make alot more by concentrating on making a hybrid Linux/Tru64 system for everything but the NonStop stuff.
Look at what SGI is doing - Compaq could learn from them.
-Erik
I've always wondered about the road Compaq was going to take w/r/t Tru64. Earlier, they had announced that the NonStop-series (the old Tandem boxes) were going to use Alphas, and the general assumption was that a modified Tru64 would replace the current custom UNIX on them.
The reasons to continue to support Tru64 on the AlphaServer series is becoming less and less - a vast majority of the neat Tru64 features are (or will be by Q4/2000) available on Linux. Performance is still in Tru64's favor, but that has mostly to do with the optimizing compiler and assembly-tuned system libraries.
In truth, I can easily see Compaq going the route SGI is going: abandon their in-house UNIX brand over a couple of years in favor of Linux, while insuring that there is a Tru64-compatibility layer in Linux.
One thing I'd be interested in seeing is if Compaq would release the Tru64 kernel as OpenSource, and try to build a complimentary kernel system. That is, modify the Tru64 kernel a bit so that it could be a drop-in replacement for the Linux kernel (so RMS could call it a Tru/GNU system! :-). I am aware that this would cause some problems (obviously, no Linux driver would work in a Tru64-based kernel), but I can't see that userland programs would object much at all. Compaq could get all the advantages of having complete Linux-compatible userland programs, and yet, we'd get a kernel that could take advantage of all of Compaq's nice HA and clustering stuff, which are considerably better than Linux (as in MUCH, MUCH better).
Honestly, as a previous poster pointed out, I can't see Compaq opening up their compiler technology right now (it's a major advantage against Intel. Who know what bubbles in the minds of Compaq Management? I certainly don't.
-Erik
First off, let me preface this by two caveauts: (1) I am a natural US citizen, so all the following is through talking with friends who've gone (or are going through) the visa thing, and (2) my experiences are relative only to the Computer Industry in the Boston, MA and Silicon Valley area.
The biggest advice that I can give to someone looking for a US-job is this: come here first. DON'T go through a foreign recruiting agency - most of my friends have had nothing but bad things to say about them. By coming to the US, you get three critical things:
Coming to the US is fairly easy - one of the best ways is to get admitted to a US university for a year - you get a student visa, and you generally have 90 days afterwards to find a job before it expires (not to mention the time you're supposed to be in school). Student Visas from virtually any 1st-world country are a no-brainer. Likewise, if you don't want to do that, getting a 90-day tourist visa is a no-brainer, and tourist visas of up to a full year aren't hard to get. Remember, neither a student nor a tourist visa allows you to legally work in the USA.
On to the second part: working for a US company when you're a foreigner. A previous poster pointed out that foreigners are to a certain extent perceived as "cheap" labor. While I do think that this is a problem, this is more a function of how you sell yourself at a job interview. If you have in-demand skills, and, more importantly, have very good English communication skills, companies aren't going to treat you any different from a US worker. Finding qualified people is very hard for many positions, so any qualified applicant is going to be zealously sought-after. Do be aware that getting an H-1B visa costs the company extra, so they might offer you slightly less than a US-worker, but I think this is a fair trade off. Now, if you see that they're offering you only 2/3 what equivalent positions are advertised at, they're trying to take advantage of you.
Do rememeber than working on an H-1B visa is a temporary thing. You're not elligible for a permanent resident visa (Green card). Technically, you can't stay more than 5 years (though, this tends to be ill-enforced). Likewise, you're not supposed to be able to apply for a different type of visa once you have an H-1B, but I haven't heard of anyone ever having problems with that (the INS doesn't seem to really care). Also, H-1Bs require that you be employed by a sponsoring company at all times (actually, I think you have something like 30 days from quiting one company to getting hired by another) - this can be a problem, as you might feel required to stay at a company since they sponsor you. This is where many foreign workers get into trouble - they get hitched to a company that doesn't treat them well, then feel trapped, since they don't have the confidence to find another job. Look at the amount of work in your field, and judge how easy it would be to switch jobs (the 30-day window isn't enforced much, but I'd be leery of pushing it too much).
You should talk to your local US Embassy or Consulate about the various types of available visas, and what the restrictions are for each. Pay close attention to the industries that certain visas allow you to work in, travel restrictions (can you come and go freely to your country or not?), and to whether the visa is tied to a sponsoring company or if it is granted to you (and thus, floats with you as you move employers).
Send me a note if you're interested in more info, and I'll see what I can help you with.
-Erik
To a certain extend, I do see your point. Alot of what I posted is indeed in the article. Next time I will try to add alot more additional info.
Perhaps I should have noted some of the interesting research being done on this:
Physical Limits of Portable Power Storage
Batteries of the 21st Century
Hybrid Electric Vehicle research
In my defense, I do think I pointed out several things that were not obvious (and people were arguing about in the preceeding posts).
I'll try for more content in the future.
-Erik
Pardon the silly title.
yes, even the smallest flywheel has gyroscopic precession problems. Yes there is a danger that they might shatter and shoot out lots of nasty fragments. Then again, your typical battery can spontaneously burst into flames, spew acid all over the place, and generally trash your surroundings at the drop of the hat. I don't see too many peole complaining about those problems.
The precession problem with flywheels can be almost completely negated by using two counter-rotating flywheels. yes, I am aware that there will be some problems with movement along the Z-axis, but this is managable in instances where there is little Z-movement (such as cars).
Furthermore, the heat problem is significantly reduces (in fact, almost eliminated) if the flywheel is contained in a sealed vacuum shell. For safety's sake, making this shell from something like kevlar would reduce the small risk associated with flywheel failures at high speed.
The biggest problem with using flywheels is that there has to be some sort of electric motor - that is, something that can change mechanical movement to electrical energy. In items like cars and UPSes, this isn't much of a problem. In your laptop (and similar compact places) this is definately a stumbling block. I wouldn't look for flywheels in laptops anytime soon.
I expect to see flywheels in electric cars in the near future, since they offer alot of advantages over a most batteries: lighter weight, a very high energy capacity, ability to deliver large amounts of current quickly (something most non-lead-acid batteries can't do), and virtually no maintenance.
Honestly, I can't wait for the hybrid car to come along: small, constant RPM gasoline engine, electric generator, and flywheel. You have a lead-acid to start the whole thing, and store any excess energy in the flywheel. Cool!
-Erik
I read the whole article, and while it raises some worthwhile points (other than the random gun control thing - what has that got to do with anything?), I think Meyer has missed the fundamental link between Ethics and OpenSoftware (I'm going to reserve FreeSoftware for GPL'd stuff).
Under the harsh light of analysis, Ethics are a set of socially pragmatic guidlines. They aren't rules (some are laws, some aren't). Instead, Ethics are social conventions that allow a given society to remain cohesive and functional. That's the extent of them. They aren't "God-given" or some other divinity-enforced, but rather religion has been used as a method of enforcement of Ethics for millenia. Something becomes Ethical in a society when a large majority of the population sees that such a rule/value is beneficial to the society. That's why Ethics change - it was highly ethical to own slaves for virtually the entire course of human history until the 19th Century, when most cultures decided that it suddenly was no longer worth the problems it caused. We now view slavery as unethical.
So how does this relate to OpenSoftware? OpenSoftware is all about pragmatism. There are differing degrees of how pragmatic one wants to be (just as there were degrees of zeal in the abolitionist movement), but the fundamental reason driving the OpenSoftware movement is pragmatism: OpenSoftware provides benefits and advantages to both the developers and users that are deemed to outweigh the disadvantages. In addition, the general viewpoint has come to the pragmatic conclusion that, for most items, closed software is inferior in features to OpenSoftware (by features, I mean advantages to the user/developer population, not bells-and-whistles).
Now, the Ethical thing here is that we have come to realize that a promoter of OpenSoftware is Good. Thus, OpenSoftware developers have high Ethical status, which is a social advantage.
The main point to all this is that OpenSoftware and Proprietary Software aren't opposed - they can co-exists. In fact, given the relative advantages of each, they both should occupy their market niche, and we should recognize that (and criticize those who engage in extremism for no socially-justifiable reason).
This "my-shit-is-better-than-your-shit" absolutism rhetoric is exactly what is unEthical. Ethics is pragmatism, practiced on a cultural level. When we (as a society) decide that one is a clear wholesale detriment to society, then it will generally be deemed unEthical. As long as both methods have defined uses (ie. markets) where their overall contributions outweigh their overall liabilities, they both should survive, heated rhetoric aside.
OpenSoftware is more about questioning the fundamental assumptions that have ruled the Software Industry than about some new large-scale societal revolution. Both sides would be well-advised to remember that.
-Erik
Not to toot my own horn here, but I both do currently work for, and have in the immediate past worked for, companies that are potentially hugely affected by the DMCA.
I'm also responsible for our possible compliance thereunder. It Sucks. It makes my job a massive bitch, costs my company a boatload of cash and time to comply with, and generally makes my life miserable.
So, you bet I'm going to be there to let them know it's not just private citizen that are sick of the DMCA. It sucks hard for businesses, too - look at all the budding e-whatever, and I-whatever companies that are getting killed by the hired guns of the big media companies.
If you want a ride Thursday, give me a call. I work in Foster City, so I'll be heading down 101 sometime around 11:30.
650-520-5080
-Erik
This is what the industry calls dedicated RAM drives. Essentially, they tend to be 5.25" full-height devices that have a SCSI-controller on the back (some of the newer ones have FibreChannel), and appear as a normal SCSI drive (just with 1000x the performance).
If you peek inside the device, it's filled with a little bit of circuitry, and SIMM or DIMM slots, and a small rechargable battery. Not rocket science here.
The problem is that they sell to a niche market, and thus you're looking at about $10/MB or more. Actually, I think more in the range of $50-100/MB. It's totally outrageous.
8GB isn't alot of RAM - I'd look into getting a good-sized Sun (maybe an E3000) or HP (like an L2000) or other UNIX box. Most of these class machines run between $100k and $300k for a 4-way config, and you get so much more for your money.
Given the current pricing of solid-state drives, they make almost no sense for anyone. Just get a bigger machine that can handle the amount of RAM you need for the DB. The cost of a 4-way E3000 w/ 8GB of RAM is somewhere around $200k, which is almost certainly less than what you'd pay for 8 1GB solid-state drives.
Industry pricing is stupid, isn't it?
-Erik
PS - this isn't unique. Look at what people want for a dedicated SSL hardware accellerator. With CPUs so cheap, it's hard to justify paying $5k for a PCI card that has the same performance as a 700Mhz P3...
I'm a gun-control advocate. However, I don't see how anything we do currently improves anything, so I'm in favor of giving up on gun-control completely.
That's right. Allow any Tom, Dick, Harry, or Jane to go down to the corner store, and buy themselves a full-auto AK-47 if they want. No background check, no license, just hand over the $300 and Presto! one nice assault rifle.
However, it should be illegal to commercially sell ammo. That's right. You can sell those nice little "do-it-yourself-by-hand" ammo loaders, but no big automated super-industrialized ones, and companies are forbidden to sell manufactured ammo.
The Constitution makes no mention of the right to unlimited ammo. Nope. You want rights - you can have the same ones that the Minutemen had - make your own damn ammo, you lazy Americans! :-)
I'd like to see how long we had a gun problem around here when you can't make 1,000 rounds of ammo for your nice HK MP-3, and you jam every 5th round since you're too hopped up on drugs to run the ammo-loader properly...
Just a thought...
:-)
-Erik