The original article (and the subsequent followup) attempt to solve a problem using a desired tool, rather than looking for the right tool for the job. A lot like the old saying "If all you have is a hammer, everything starts to look like a nail."
The base problem that I think he's trying to solve here is that software quality is abysmal. That is, all commercial (and most free/open) software is riddled with bugs, many of which are well-known at ship time, but haven't been fixed.
Making source code available (whether as Open Source, Free Software, or a eyes-only copy-restricted) is orthagonal to this problem. yes, maybe, it could help. But that's incidental to the Free/Open software movement. And (as many people have pointed out), there are many problems with providing source with all programs, most of which are massive barriers to any help with quality of the software.
The fundamental flaw here is that commercial software's quality is the producer's responsibility, not the target audience's. In Free/Open software, the developers and audience have significant overlap, so it can be truly said that the audience can help quality. This is patently untrue for closed-source programs: the development community is very tightly controlled, and the user community has no real method of influencing quality (other than by not buying the product), even if provided with the source code.
So, this leaves us with the case of how to make the developer's produce better quality software. Fundamentally, we do this the EXACT SAME WAY all other industries insure minimal quality control: LEGISLATE IT. There are oft-quoted sayings about "if the car companies built cars like software companies build software..." and others to that effect. They all point a massive discrepency in the legal status of software: it doesn't play by any of the traditional product-liability and quality-control laws that every other product industry abides by. Yes, that will change the nature of the software industry: that's the point. And NO, it will not harm Free/Open software (as gifts - i.e. giving away something - are not coverd bty under the various product-liability laws)
You really want to fix the software quality problem? Require that software companies have a warranty of fitness. Require them to refund money for defective products (opened or not). Make them liable for damage caused by known defects. In short, treat them like anybody else. Software isn't special. It's time the software industry grew up.
See my previous post on why the software industry should quite being treated like a spoiled teenager.
The problem is real. The solution provided by the article is wrong. I'm right.
First off, these are my experiences based on looking for a job in 1993 in Boston (which was right before the tech boom, and at the tail end of the early 90s recession). This should be generally good advice, but I can't speak to its effectiveness outside a major metro area.
Forget on-line jobs boards. They're useless, and companies aren't using them anymore.
Talk to your Advisor and any Sr. Professors you know. These people often have good contacts inside local industry; they may know of some openings, or, more likely, can refer you to people who might know. Such professors often have several critical contacts which can be of immense use to you: (a) they know previous students who have jobs in the area (b) they know companies that they work with for research/sponsorship (c) they tend to have a social circle which includes senior and executive types who know about the local market and openings.
As a correllary to the above, Network. Tap on sponsors of any work-study project or lab you might have been affiliated with. Ask your friends about their family's professions and any contacts which might be possible through them. If you've friends who already have graduated (and have jobs), ask them about what's going on in their company. It might even be good to interview with those companies (even if they're really not hiring) to learn the interview process and make some additional contacts if possible.
Feet on the street. Do some research about the industry in your area, and start visiting companies which look like they're doing OK. Physically visit them and ask to talk to an HR or tech manager. Don't expect to get to see them then, but try to get an appointment to return. This kind of pro-active searching really gets people's attention, and will often open up doors to jobs which were "internal-only" or otherwise unadvertised. Of course, when you're doing this, dress professionally and have a well-done resume and introductory letter available to leave with the company.
Find a good recruiter, as they can find openings which are unpublished or just starting to open. Finding a recuiter is hard, as evaluating one at your stage of the game is difficult. In general, look for a couple of things: (a) if you're turned down for a job after an interview, ask your interviewer about recruiters they deal with which they consider good (b) don't go with one which advertises much; good recruiters build their business by word-of-mouth (c) a good recruiter should spend at least an hour with you Face-to-Face talking about your strengths, weaknesses, and goals, and should talk with you immediately after every interview they send you on.
Understand that the economy is down, and you're looking for entry-level work to gain experience. At this point in your career, I'd be making it clear to potential employers that pay is secondary to a job which can help you grow. An employer with some interesting (to you) work may be wavering about opening a position at $40k, but consider it a no-brainer at $25k. This works particularly well at smaller companies, which realistically desperately need help (and thus have lots of stuff for you to learn about), but don't think they can afford it.
I lived and worked in Boston for 7 years professionally, never making more than $40k. In fact, I started out at $27k, and usually worked 70+ hours/week for the first 3 or so years. I lived in my own apartment, and paid all my bills without going into debt. It's not really that hard, you just have to be careful and put off anything not completely necessary (like buying a new car, going on major vacations, good furniture, et al), and consider your first couple of years as an apprenticeship. Learn how businesses are run, and suck up all the experience you can. That will give you much better leverage to move upwards around 2006 or so, to a job with less hours and probably twice the pay you started with in 2003. And employers will be willing to pay it then, as you've proven yourself. 10 years after graduation, I now make well north of $100k, and consider it the payoff for being overworked/underpaid for much of my 20s.
Realistically, what you should be after is a completely open Network Acceptible Use Policy decision process. All users should be able to involve themselves in this process (students, faculty, administration, IT staff). During this process, the different groups will bring different desires to the table, and then be able to hash out an acceptible solution for everyone.
Realistically, there will always be some restrictions on what is considered "proper" network usage, since network bandwidth is a limited commodity. By having an open NAUP process, everyone has the chance to fully understand the limitations required, and contribute to the policy.
My suggestion it to propose an NAUP "board" with a representative from the above groups responsible for writing and approving such a policy. They should have the power to create and enforce such a policy, and the power to deal with any reprocussions thereof (e.g. if more bandwidth is needed to support the desired features, levy a fee on the appropriate user base).
1) Laws don't Prevent anything. They assign penalties for certain actions. As such, they serve as stimulus to modify behavior. You shoudn't be looking to prevent someone from doing something using the law. That's the trap we're in now - the only way to prevent a potential "bad-guy" from doing something is to lock up everyone, good and bad. If they're copying your program without buying the appropriate number, they've broken the law, and you're entitled to damages.
2) Quality laws do fine now for both the small guy and big guy. Both have to adhere to the same level for making suring that the quality is there. I'm not going to cut my local store more slack for selling me shoddy merchandise than I would WallMart, simply because the local store is "smaller". Obviously there has to be a certain amount of leeway for QA in software (i.e. it can't be perfect, but...). There has to be a minimal barrier-to-entry for producing software, and QA is it. Everyone is held to the same standard, and if the standard is written correctly, then it won't be too burdensome. However, you might need product-liability insurance, like many traditional manufacturing busineses...
3) This goes back to the original statement: you need to be able to provide them with a method for returning the merchandise, but you generally don't have a guaranteed method of locking out cheaters. As a rough analogy: what prevents me from buying a 42" TV, using it for a party that weekend, then returning it on Monday? I'm cheating the retailer, but that's not really detectible. The vast majority of people will pay for a properly priced product, rather than cheat. And if you do it correctly, someone with an "illegal" copy isn't going to be able to get upgrades, support, documentation, et al. And yes, part of your company will have to deal with maintaining serial number collections. That's part of the business. TANSTAAFL.
Right now, being a software company (both big and small) allows the company to sidestep a huge number of obligations that non-software companies take for granted as a cost-of-business. I see no reason for this, and in fact there is a considerable social cost to absolving the software companies of these responsibilities. If this reduces the number of potential small software companies starting up, then so be it. We have to get out of the mind-set that a software company can just spew random crap at the EU. There has to be some responsibilities with producing a product, and these responsibilities cost money.
I'm actually not that unhappy that the tech bubble and its attendent fawning are gone. Sorry about all those without a job right now, but in the long run, it's better...
Somehow, the technology sector was promoted (and believed) to be "different" than any other sector in history, and therefore we couldn't, possibly, no never apply the same logic that we'd used to analyse other sectors at it. Look where that attitude got us.
I'm not saying that we shouldn't look at technology with fresh eyes as to the benefits and possibilities it brings. And I'm definitely not for forcing all technology into previously-defined cubbyholes via direct legal analogy (e.g. it's the Internet folks, not some fucked up mutant telegraph or road system. Look at the new paradigm). However, that doesn't mean we can't learn and use previous analytical and legal tools to help mold the direction of tech.
I'd actually love to see a good chunk more of regulation in the "tech" sector, which actually also includes the "Intellectual Property" sector. We really could use:
Real Consumer Protection Laws. Just like buying any physical object, whether a vaccuum or car, my software better come with an enforcable warranty of fitness. And I should be able to return defective merchandise, no questions asked (even if I've opened the shrink-wrap).
Product Liability for Bad Quality. Why the hell don't standard QA laws apply here?
Real Contract Law. We have 500+ years of Common Law on what constitutes a real contract between two parties. Now, suddenly, the tech and IP sector want to redefine that because the old way simply "doesn't apply" to their paradigm for some reason (primarily because it's not to their liking?)
Similarly, Application of Traditional IP Standards This whole concept of "licensing" a copy of a problem is bullshit, the same way that "licensing" a copy of a book or music tape was 100 years ago. And we had several hundreds of years without patents on anything other than physical devices. WTF?
Level Field for Taxation. I see no reason why local sales taxes shouldn't be normalized and then applied to purchases bought on line. There's no real excuse not to tax catalogue and Internet retailers the same as local ones.
Actual Oversight of Company Finances. This isn't a tech problem per-se, but the biggest egregarious sinners are tech companies, and tech in general doesn't seem to think that the way they did things in the 90s was bad. Another "we're different, so the rules don't apply" delusion.
Better Labor Law Enforcement. WTF is up with standard 80-hour weeks for tech sector? The enforcable "non-compete" clauses? The "own-your-brain" shit? The royal clusterfuck that is the H1B program (oh, it could be such a great thing, if it wasn't run so badly...)
Tech needs to stop with the "we're special" attitude, and get back into the real world. This includes getting a bunch of regulation and responsibilities. Right now, the tech sector is behaving like a spoiled teenager. The sooner it grows up and realizes it needs to play by the same rules everyone else does the sooner that politicians (and everyone else) takes it seriously again.
... or don't we see chipset manufacturers avoiding the hard problems completely? I realize that cost is an issue, but for the most part, we're talking about high-performance workstation and server boards, which cost $500+ or more.
The biggest issues these days are:
Data Starved Processors - and this is all about latency (and, to a lesser extent, bandwidth) to main memory. I don't care if there is DDR400 memory support, what I want to kow is why isn't there a L3 cache? I mean, even the high-end Xeons these days have a max of 1MB or so on-die L2. Sure that's great, but do you know how many common datasets blow right through that? It's often dozens (if not hundreds) of cycles to access main RAM. The alpha architecture did L3 on the motherboard way back in 1994 or so. Why don't these modern server chipsets support 16MB or so of SRAM for L3 cache? Hell, they should probably support 64MB or so.
Improved hyperthreading support - go check out the Ars Technica article on this. Hyperthreading can potentially really help performance, but it's being held back by (among other things) problems with cache coherency and loading. While much of this is on the CPU (and thus, a chipset can't help), there are a bunch of stuff that could be moved into the chipset for help.
Useful shit in the Chipset - ATA/133 isn't that useful (vs ATA/100). Firewire is OK, as is USB 2.0, but what I want to know is where are nice stuff like block data copy between video and RAM (like the SGI chipsets for the Indy/O2 had) for high-performance video processing? AGP is a joke for this (as anyone doing video processing will tell you). These chipsets are aimed at workstations, after all.
Standard interfaces for custom silicon - no, I'm not talking PCI-X or crap like that. There should be a standard interface directly to the chipset for people who want to do custom silicon ASICs and have them have direct access to the high-bandwidth internals of the chipset. I mean, even in the low end, why should a FCAL controller chip have to pass the PCI bus? Or a hard-core encryption coprocessor? Or a hardware routing ASIC? All need several GB of bandwidth directly to memory (or each other), and I can't see any reason not to have them surface mounted next to the north bridge with a dedicated interface.
Unfortunately, there seems to be little innovation going on in chipsets these days. The high end looks very, very, very depressingly identical to the cheap consumer crap. WTF folks?
Unified System Documentation I want all docs in a single, standard format that all programs must write their basic documentation in. No more man, info, html, pdf, ps or whatnot. I'd prefer a fixed SGML DTD (docbook is OK, but I'd prefer a designed-from scratch one specifically to address the system documentation target). That way, we can can get good viewer independence with modern features (hyperlinks, fonts, in-line graphics). All of the current formats are lacking in at least two areas, and we don't have agreement on which to use. This is a big place for them to step up.
Standard Config Files No, this is not a request for a Registry (the merits thereof are for another discussion). What we want here is to get rid of the 80 billion different ways to write a config file. I'm sorry, but they all should be a nicely tagged XML (or similar) file nowdays. It sucks to have to figure out the idiosyncrasies of the various config files. This issue isn't simple, but is definitely a place where a good discussion is needed.
I'm going to give you a short summary of the various computer-related professions for someone looking for entry-level work in the UNIX field:
Systems Administrator - this is probably what you're thinking of right now. This entails a huge variety of skills, from installing hardware and basic system OS, managing system configurations and upgrades, user management, system troubleshooting, etc. Basically, you're responsible for making sure that the computer systems (usually servers, but sometimes desktops) are up, available, and working properly, and that everyone can access the information on them as appropriate. A little bit of DBA and programmer skills thrown in is a good idea too.
Network Administrator is related to SysAdmins, and often shares similar workload and skills. However, the emphasis is on networks - design, troubleshooting, maintaining and configuring network devices (switches, routers, NAT/firewall devices, et al). Typically, both LAN and WAN knowledge is required, and a certificate (or equivalent experience/knowledge) in CCNP is a good idea.
Systems Programmer (including Embedded Programmer) these are folks who write systems-level code. That is, drivers, kernel modules, low-level libraries, and in the case of Embedded Programmers, work on devices which aren't quite what most peope think of as a computer (i.e. firewall devices, etc.) Typically, you'll need some very low-level understanding of how software interfaces with hardware, a good bit of hardware knowledge, and primarily C and assembly programming experience. A very good grasp of algorithms is also typically important, as the code produces generally needs to be as efficient and compact as possible.
Application Programmer write user-land programs (word processors, order processing/entry systems, inventory tracking systems, etc). This is what people generally think of when they say "programmer". Java and C++ are the dominant languages here. These days, a good understanding of SQL is a good idea too, since most custom apps talk to a DB.
Webmaster is more than the stupid morons that have been doing it for the last 3 years. It combines a bit of graphic artist with a modest programming ability (primarily in scripting languages) and a dash of SysAdmin thrown in. In general, a good webmaster has site management tools for deployment and tracking of the website, is concerned with performance and maintainability, and also has a hand in the design and coding of section of the site. Perl, Python, PHP, JavaScript, and Java (for JSP) are good languages to know.
Toolsmith is not terribly well known. However, most large organizations need someone like this, which is typically a junior programmer or junior sysadmin detailed to do the work. It involves building common tools for everyone else to use. Typically, this include downloading, compiling, deploying, and maintaining common OSS tools (e.g. keeping a working Perl setup for 6 CPU/OS architectures with all the needed modules). It often also includes work with all the other professions here to find out what they need to do their job, and create it. The person here typically has lots of scripting experience in 4 or 5 script languages, plus decent coding experience in 2 or so "real" lanuages (C, C++, Java, et al), and understands how to write small programs quickly. In essence, the Toolsmith is the person responsible for producing the company's Swiss Army Knife collection of programs.
QA / SCM is Quality Assurance (e.g. Testing) and Software Configuration Management. Being a Sr. QA person is a real good way to move into either Toolsmith or Application Programmer, since you gain a whole lot of knowledge about how things work (otherwise, how are you to test it correctly?), and get good at automating test stuff. SCM is often a gateway to SysAdmin, but is different, in that it really is concerned with change management, deployments, and usually builds. Both positions require a good smattering of script language knowledge, some programming experience (enough to read other people's code and tell if it's doing the Right Thing, but not necessarily able to write it from scratch), and a good head for organization.
DBA isn't really in this category, but I thought I'd mention it anyway. Most DBAs have a bit of SysAdmin experience on the platform that their DB runs on, but the rest of their knowledge is tied up in the very different field of SQL and Database software.
I can't give you specifics, because they depend on the field you're looking to enter, and more importantly, the details of the job, which vary widely. I hope the general descriptions above help.
...this actually looks like a very useful tool. Originally, I was going to write it off as another feel-good kowtowing of the modern world to kids' micro-second attention span, but the article actually makes it sound truly useful, especially the parts where they find it helps Mom and Dad who don't speak English as well as they would like.
I'd even go so far as to say that it can replace a major chunk of "homework" for these kids. Even better, it seems to eat up time normally occupied by traditional video gameplay, which is basically useless (other than purely mindless entertainment). All-in-all, sounds like a good thing.
My sole complaint here is this: the more we try to package learning as entertainment, the less we seem to emphasize that learning for its own sake is fun and interesting. And we also seem to be reinforcing the concept that it has to be FUN in order to be worth doing. Sadly, the world doesn't opperate this way, and I think we're doing a great disservice to kids if we get them thinking that learning has to be somehow immediately entertaining.
I realize this is for younger kids, where we don't have this problem so much, but I want to make sure that at some point, we start reinforcing the notion that learning for knowledge (and problem solving) are their own rewards, and don't have to be wrapped up in some entertainment package to be worth doing.
To have a "succesful" voting system, there are several important criteria to accomplish:
Clarity and Usability: The system must be clear and unambigously present the voting options to the voter.
Correctness: The system must prevent a user from making an invalid choice. Very good systems should immediately notify the voter of an invalid choice, and provide and explanation as to why it was invalid, and how to correct this problem.
Robustness: The system must not fail to count a vote, or provide a mechanism to notify the voter of a system problem during voting.
Trustworthiness: The system must be designed to make cheating as difficult as possible.
Accuracy: The system must accuately tally the votes cast, and prevent multiple votes from the same voter.
Authentication and Anonymity: It must be easy for a voter to register to vote, and the system must accurately identify a voter as a valid user. It should NOT be possible to trace a vote record back to a specific voter.
Verification: It must be possible to verify the total number of votes received by a candidate, and verify this against the total number of voters.
Satisfaction on all accounts is difficult, and not just for electronic systems. Most current systems fail considerably on at least one of the above requirements.
The sad thing about this boondoggle is that there is a relatively good solution that can be made into a great solution with a little effort, but people seem to be ignoring it:
1920s-style mechanical voting booths
These booths are designed to mechanically prevent incorrect voting (e.g. you can't flip the level for multiple people for an office, unless specifically allowed for that election), they hardly ever break (and if they do, it is readily apparent to the voter in virtually all cases that something is wrong), they leave a mechanically punched card with the voter's actual vote on it for later recound (none of those stupid hanging chads with a mechanical puncher), and they provide a quick summary of the running total of votes on the back via odometer-style readouts. The voting itself is clear, as the voting panels tend to be large with lots of space for names (and even pictures), and a small lever for voting immediatly overtop of the candidate (e.g. if you vote for a candidate, the lever covers the person's name/picture).
Voting booths aren't perfect - you still need a good voter registration system, and an automated vote-reporting mechanism to report votes back to a central location would be good, but the overall solution is far superior to anything I've seen proposed so far, except in one aspect: price. Nobody makes these machines anymore, and they are large mechanical items which would most likely cost $10k or so each. But they last forever (I mean, I voted on one at home in 1990 which was made in 1934). What's the life expectancy of some of the proposed electronic machines? 10 years, maybe?
There are good solutions out there. We just have to look for one, and not be trapped by assumptions about how it must look.
First off, all the suggestions in the post above by chrismcc (here) are excellent. I am going to expand on them a bit.
First, you really should have an AS number and get a dedicated IP allocation from APNIC - it will be immensely useful, and save you a whole bunch of money and headaches in the future. There are some upfront fees (I just checked, and a/19 (32 class C) runs about $8192, with an AS number cost $500, both of which are one-time fees, and you don't have to be an APNIC member), but they're well worth it, and not excessive.
After you get the AS and IP block, talk to your new ISP and your old ISP. Advise them that they will need to be advertising your AS now.
If you don't already have it, upgrade all your border routers to support BGP, so you can actually use the AS number, and also so you can potentially use multiple different ISP pipes for redunancy and load balancing. Depending on your setup, this might cost some money. However, given your setup, I suspect that you don't have anything more than a Cisco 3600-series border router, which is fine (and the BGP upgrade isn't very expensive).
Using the new APNIC address block and AS number, number all your network equipment with the new IP space, keeping the original IPs from the old ISP in place.
Have the new ISP begin advertising the AS number and your new IP block. Do some testing from outside to make sure you can reach all segments of your network.
For all important machines and equipment (primarily servers, but stuff that generally retains a static IP), give them a new IP. Almost everything supports virtual interfaces now, so it's trivial to have two different IPs assigned to the same machine these days.
Do some more testing, to check that you can reach these machines via the new IP (do both internal and external testing, as required).
Update DNS to include both the new and old IP for all assigned machines. Change the TTL to something VERY LOW, like an hour or so.
Test DNS starting the next day, and do repeatedly for the next 3-4 days.
Update any servers providing DHCP or BootP or similar dynamic service to provide IPs from the new block. Continue testing.
After about a week of running both the new and old DNS entries in parallel with all machines assigned a NEW IP address, consider removing several of the DNS entries for the old IP space. Do this, and check to see if anything breaks. Fix it.
Remove all old IPs from DNS. Wait a week or so to see if anything lingering breaks, and see if you get any reports from outside as to problems.
Remove all of the old IP numbers from all machines and network equipment, and notify the old ISP that you have completed renumbering, and that they should change routing so that IP space no longer points to you. Inevitibly, you probably will run into something you missed. Fix it.
Ditch the old ISP, or keep them for redundancy/load balancing, but make sure they're publishing your AS number and new BGP information.
Many of these steps above will require coordination with your client companies. However, if you do it right, there should be NO DOWN TIME, and the transition will be transparent to your clients.
DOJ crawls through the P2P networks, scanning your file swapping list, and arresting everyone it can find which they believe is illegally sharing copyrighted materials. They prosecute a buch of big-time file-sharers, winning some, losing others. But they get enough that it scares most people.
The big P2P sharers leave the networks. Usage drops drastically. However, the P2P software makers are still in business, as they are now left alone. Music is still being shared, only now its stuff that explicitly has been allowed by the Artists to be shared.
Now that the P2P network isn't clogged with NSYNC tunes, people actually can find (and listen to) stuff that isn't on ClearChannel or the other big chain Radio stations. Bands have small successes - releasing 128Bit MP3s to the P2P networks, and selling 256Bit ones on their websites for a couple of dimes. It becomes possible for a regional band to make a few tens of thousands of dollars of MP3 sales per year (100,000 sales @ 40 cents each adds up), and people start to flock to the P2P networks again.
Big-time artists notice it. Those which are in controll of their catalogue (through foresight, ownership of their label, or lawsuits), decide that its possible now. Somebody big tries it, and makes a couple million in sales on their back-catalog in the first month. The artists drool, as they see 75% profit margins on per-MP3 sales, with nothing going to the label (or other middlemen).
Artists flock to the P2P networks to sell their songs, and the big labels are reduced to what they really are: promotional marketing houses. Artists contract with them for fixed fees (or precentages of gross receipts) to do promotion and such, and label no longer get ownership of the music, as Artists now have the means to say "Fuck You" if the label demands it.
I'd love to see this scenario, and I think it's realistic given two BIG "ifs":
IF they really start to clamp down on the big P2P users with huge illegal catalogs, so we can get all the infringing crap off the P2P networks. Once it's all legal and above board, you can start running real marketing analysis and do the business case studies that you need to make it a real sales market and distribution channel.
IF the artists continue on the current road of fighting to get ownership of their music. If they quit (and continue with the Faustian bargain of their soul for 15 minutes on MTV), then it's over. I'm hoping they have the backbone to stick it out.
And realistically, isn't this what we want? P2P networks with LEGAL music for us to try out and see what we want? And an economically viable way for the artists to produce music and get paid for it in a reasonable manner?
Call it what you want, but sharing copyrighted MP3s right now is definitely illegal, and in the long turn, harmful to everyone. Don't do it - it's NOT the Right Thing.
.. is exactly what NASA needs to revitalize it. Right now, NASA is a massive beauracracy that does everything over-budget, late, and overtly-cautious. It's a typical agency that has outlived it's usefulness, and lost sight of its mission.
Together, Russia and NASA can come up with a good design for a Mars-mission vehicle. Unlike the Space Station (ISS), there are a huge number of unknowns which would have to be dealt with, and consequently, novel innovations for them cooked up (we got a huge amount of cool stuff out of the space program from the 60s, but nothing really interesting in the 80s and 90s). Here's a short list of totally new problems which would need to be solved:
Cheap (i.e. less than $10 / lbs payload cost) Earth-to-Low-Orbit lift capability (may rockets aren't the right thing here... Maybe giant sling shots, high-speed train jumps, etc).
Long-term space survial without resupply. Even Mir got a shipment of food/air/spare parts evey month or so. Given that a Earth-Mars mission is about a year or so, we'd need to figure out how to make such a spaceship almost totally self-sufficient.
Micro-meteoroid and radiation protection. Unlike earth-orbiting stuff and even the Moon mission, a trip to Mars is outside the Van Allen belts, and also away from the Earth's protective Solar Wind profile. Protecting a ship is a whole new ballpark.
Long-term reliable energy production. Would it be nuclear? Some sort of solar sail? Or what?
I'd imagine such a ship would require a substantial fraction of a MegaWatt of electrical power. Where is that coming from?
Long-term human psychological studies - your crew is away for at least a year. Do you use women? What about personality conflicts? Interpersonal relationships? Dating? Only married couples? The shrinks would love this.
NASA really needs a kick in the pants. Unfortunately, that requires some leadership and real vision from the President, and we haven't had that kind in awhile. They really should relegate the lift capability to private industry and just concentrate on making the Mars ship.
Given the technological design behind SSL (in that it operates immediately above IP, and below TCP/UDP), the summary you provide above is true.
That is, you can set up a cluster of web servers behind a typical redirector. Say Server A, B, and C. Each machine has a different IP address, which is a routable address (let's call it w1.foo.com, w2.foo.com, w3.foo.com). There is a single IP address for the "master" domain (say www.foo.com). All machines are set up to serve www.foo.com, both HTTP and HTTPS. For normal HTTP requests, the redirector does it's thing, with EACH http request coming to www.foo.com being served by the next available machine. Any connection a client makes can potentially be served by any machine.
However, since SSL operates below the TCP/HTTP header, a client making a SSL connection to https://www.foo.com will initially be load-balanced across the machines. However, for the rest of that SSL session, it will continue to communicate ONLY with the machine which initially answered the beginning SSL connection.
This isn't a real big problem for most web apps, since each connection is really just getting a bunch of web pages. If the server goes down, you simply have to push RELOAD on the client, and it re-initiates the HTTPS session, getting another machine to answer. It can be a serious problem with other SSL apps, as the termination of a session by the loss of the answering machine may make it difficult to programatically re-start the session.
Just to make this clear: each time a client initiates an SSL session, it gets bound to a single server. This server may be different for each session, but remember that a "session" may include many data requests.
There is no problem sharing certificates between multiple machines (as the cert is tied to hostname, and it's easy to duplicate across multiple web servers). It's an SSL protocol limitation.
There are really three seperate categories you get into once you're considering moving data from primary storage. You seem to be asking about the first, but I'll cover all three for completeness.
Near-line (a.k.a secondary storage)
Primary storage almost always consists of the fastest hard drives directly attached to your data source (file server, SAN, workstation, whatever). Historically, near-line has been some medium where the end-user could access the data required in the same manner as primary storage, but at a slower rate. The old solution used to be either a different server using older/slower disks, or an RW optical jukebox. Near-line storage almost always is very high read-usage, but the occasional write isn't unlikely, so you generally want a media that can support writes.
Backups (a.k.a. save-your-ass storage)
Backups are a place to temporarily save data in case of an emergency. The criteria generally don't include re-writability, but do concern with ease-of-access in the case of a recovery. In addition, Backups expire - after a certain period of time, the data is no longer available. Tape has been the choice for this for a long time, with it's high storage capacity and low cost. Higher-end solutions have been the "on-line snapshot" capabilities of SAN and NAS devices (essentially to make a static mirror of data on extra storage space). CD-R and even floppies have been popular for the low-end. Whatever the choice is, the main concern is reliability, and the ability to backup the data within a set time window.
Archival (a.k.a save it for the history books)
This is a big one, and one frequently misunderstood. The two major criteria for Archival purposes are Survivability, and Retrievability. That is, the solution has to make sure it does NOT degrade with time (i.e. it doesn't introduce errors after sitting on the shelf for 20 years) and that you will realistically have a method to retrieve the data over it's lifetime (e.g. are they still going to have devices that can read your data media in 30 years?) Magnetic tape is a BAD THING for Archival purposes, despite its common usage. It fails on both tests. Mastered CDs (NOT CD-R) and Optical Disks are generally the preferred method here.
In the modern world, I would recommend a backup server using RAIDed IDE drives for Near-line these days. The relative cheapness of IDE drives, combined with the newer IDE RAID cards provides an unbeatable cost/storage/reliability ratio (far superior to CD, DVD, Tape, or Optical Disk), and it's by far the easiest to maintain and use, since it's simply another fileserver. Don't scrimp, however. A good one of these should probably run $3-$4k with 8-10 100GB drives, redundant power supply, and hardware RAID.
Backups are a bit more complex, and the variables make a one-size-fits-all recommendation unrealistic. And you didn't ask for that anyway, so I'm not going to make one.:-)
Archival really means you want to keep (or are required to keep) the data around, but don't need access to it much. If you don't intend to keep the data for more than 15-20 years, you can probably get away with CD-R. Otherwise, look into having your data pressed onto CD (i.e. real mastered CDs). They last a good 100 years or so, and it's relatively cheap. In either case, you want multiple copies of each disc, and the good-old CD-jukebox is your friend.
As you imply (and other posters have noted), DVD-R/RAM/RW/+RW isn't quite stabilized yet. Despite their larger capacity, I wouldn't change the above recommendations, other than replacing CDs with DVD when it settles down - DVD mastering isn't anywhere as cheap as CD mastering is (and if you do master DVDs, make sure that you specify UNENCRYPTED DVD so you don't get CSS put on accidentally).
As a side note: there's a whole industry built around Hierarchical Storage Management (HSM) which deals with automatically moving data between the various storage levels, and recovering it as need be. It's a bit beyond what you describe you're looking for, but look at one of the big UNIX storage players' (Sun, HP, IBM, EMC) site for a whitepaper on it. They're a good read for concepts which you can apply, even if you're not using their multi-million-dollar hardware/software packages.
I've read the proposal that passed the European Parliament, and if the policy the Bush administration is attempting to put in place is similar, then it won't pass Constitutional muster. It fails on at least three major points:
It attempts to require a private entity to perform an action that is explicitly forbidden to the government. The government does NOT have the right to monitor all traffic (be it email, web, internet, snail-mail, phone, or whatever) without a court-order, and can only invoke the National Security exception in narrowly-defined circumstances. In this case, the government is attempting to make an end-run around this prohibition by requiring a private source to do the collection; however, the courts have consistently ruled that the private party is acting at the behest (and defacto control) of the government, and therefore is under the same obligations and restrictions as the government.
A bunch of legislation passed in the 1990s grants ISPs "common carrier" status. One of the central legal tennants of Common Carrier is that it is traffic-blind. This applies not only to the carrier itself, but any organization attempting to force the carrier to become traffic-aware (ie know what is being transmitted). Common Carrier is a very well-established concept, and such a executive policy cannot overrule a legal precedent such as it without an explicit law from Congress.
finally, practicallity is an issue. The government can legally require that I prove I'm a green Martian before taking an airplane trip, but it won't pass a court challenge because it is an impossible requirement. A slightly less extreme standard is known as Onerous Burden, wherein a plaintiff can contend that such legislation or regulation places an unreasonable burden to comply with it; such a case would be (for example) if port fees to dock at a port exceed the value of the ship docking there.
I don't think they really realize the volume (either the US or Europe) as to what they're requiring, either. A rough estimate is that an email header is 1k, and that a log of an http request is.5k. For an average user, 1000 http requests (remember, each picture/icon is a new request) and 10 emails per day would be typical. That's about 500k per person per day. For a mid-size ISP with 10,000 users, that's 5GB per day, 1.825 TB per year. Even assuming good compression of 90%, that's 180GB per year. Given that you would need to get a good machine and lots of redundancy for it (remember, this is a LEGAL requirement), I can easily see it costing $30k PER YEAR or more for the hardware alone for log space (plus the additional costs to upgrade the routers/mail servers/proxies and other infrastructure to allow for such vast logging in the first place). I'd estimate that it would be at least triple that, when all other factors are included. Even a $30k capital expenditure per year is a pretty good chunk of change for a company with a probable revenue stream of $3M per year. That's a 1% value of gross receipts (conservatively). And what about someone like Earthlink or similar, who has millions of customers? You're looking at requiring Terabyte storage systems costing multi-millions of dollars.
Even though I've seen some really dubious legislation and policies over the past 10 years (e.g. DCMA), I don't think this one will fly.
You're confusing some of the performance characteristics of the ATF (which turned into the F-22 Raptor) with the JSF (the now F-35).
The F-22 is a high-performance, air-superiority fighter intended to superceed the F-15. It has a 2nd-gen stealth (very low radar cross-section and low observability infrared/visible features) design, coupled with a high speed (~ Mach 1.4 without afterburners, ~2.2 full burner), and is primarily a missile-platform (ie, no bombs). It is the premier air-superiority fighter in the world.
The F-35 is a ground-attack AKA strike fighter (NOT a close-support aircraft). It tops out at about Mach 1.5 or so at altitude, and is not anywhere near as stealthy as the F-22 (though much, much better than the F-16, F-15, or F-18). One version will have VSTOL cabilities. It carries laser designators and other ground-attack sensors, and has a modest bomb-load (though smart weapons will be it's primary payload).
All things said, the F-35 is a good design, and a reasonable compromise on cost, performance, and advanced technology. HOWEVER, it is NOT an air-superiority fighter (though the Royal Navy will use it as such off their carriers), neither is it a dedicated close-support aircraft (though the US Marines will use is in such a roll). It is primarily a multi-role strike craft. It's really a blend of the features of the F-18, Harrier, F-16, and F-22, with some compromises.
The A-10 will probably remain the best close-support aircraft around for general use (the Harrier and similar craft are superior, but only in specific uses), and the F-15 and F-14 (and of course the F-22, plus the MiG-29) are better air-superiority fighers.
My major concern with the F-35 is the low payload cability compared to the F-16/18 (though it's superior to the Harrier). It's probably OK, since it looks like the "bomb dumptruck" role of massive dumb firepower is being relegated to the B-52 bomber and AC-130 gunships these days.
I'd have to say the most "expensive" bits of information had to be the notes that Klaus Fuchs passed from the Manhattan Project to the Soviet Union. Estimates I've seen are that the material was no more than four dozen full pages, but that material was the key to allowing the Soviet Union to finish their Atomic bomb research years ahead of time (providing at least a 5-year jump). For an estimate of what the Manhattan Project cost, look here. For a conservative estimate, I'd say that those 50 pages (~2000 characters each = 100kB) saved some $10 Billion in research costs. And that's in 1945 dollars.
The German, Italian, and Japanese cypher codes were similarly valuable, though not quite as expensive to obtain.
Historically, I'd say that the $50 in trinkets that Dutch explorers paid to the Native Americans living on Manhattan Island for title to their island (ie, for the signature on the treaty giving the Dutch what became New York City) was the ultimate rip-off (or, great deal, depending on which way you look at it). Signature = ~25 bytes, with current value of the Manhattan Island real estate well north of $10 trillion.
As a side note, the US (and presumably the other nuclear powers) does NOT maintain the "Launch Codes" at the political level. These are AUTHORIZATION codes, which tell the military that a valid order to launch exists. The military maintains the actual launch codes (at different places for different weapon systems), so theoretically, it is possible to launch a nuclear weapon without permission. For obvious reasons, the military designs launch systems so this is as difficult as possible.
Specifically, he's limited his view to the programmer who works for a company which is in the business to sell software. That is, where the company makes its revenue by the sales of software to someone. In that case, the programmer is the primary revenue-producing asset of the company, and there are significant reasons why Open Source isn't always the best way to do things in this market segment. In fact, I would argue, that for software-only companies, Proprietary is the best way to go for the vast majority of them. Not all, but clearly, most.
However, what he fails to understand is that software companies are at best a vocal minority of companies which produce software. Virtually all Fortune 1000 companies have staffs of in-house programmers writing custom apps. ALL government agencies have them. Hardware companies (or those whose primary interest is in selling PHYISICAL devices) have legions of programmers whose sole purpose is to cook up neat programs which help them sell their hardware. Even people such as IBM global services sell contracting time/expertise, though they produce significant software for their clients.
This second category is where Open Source makes the most sense, and where I would argue will eventually smother Proprietary. Sure, I can see companies (and organizations/governments) buying Proprietary software from the software-only companies (because it's cheaper/faster/easier to get it from them right now), but I'd expect that the mid-term results of going totally-Open Source for all code produced by them will win.
So, to quote from Return of the Jedi: "...you're going to find that many of the truths we cling to depend greatly on our own point of view." The author may very well be right in the localized case, but I sincerely think he's wrong for the general one.
..I always wondered how Canada could possibly have much lower rates than the US.
I know how much it costs to put in DSLAMS. I know what the monthly equipment space rentals are at Central Offices. I know what it generally costs to maintain the network infrastructure to support a DSL userbase. And, let me tell you, for $40/month, people like us aren't making huge profits (mind you, we do make money now, but not in the bucketfulls that people here seem to be implying).
Even considering being an ILEC vs a CLEC here in the USA, about the only way I can see the big Canadian DSL providers being able to provide such cheap service is through subsidizing them, either from their other (e.g. voice) businesses, or from the government (e.g. tax credits, direct payments, "access fee" taxes, etc).
Don't get me wrong - that's a perfectly valid way to deliver cheap broadband. The USA did it with Voice service. However, I'm not sure that's the best thing in the long run for Data. In the end, I expect that Voice and Data regulations here in the USA will converge (since there really is no sane reason for keeping them apart anymore). I'd rather see a bit less regulation than tying the whole data network up with the mess of voice regulations. (which isn't the same thing as the ILEC's want - they want voice and data to be UNregulated. Not a good thing either, so long as they control the physical last-mile).
Anyhow, the current price see-saws in the USA are an inevitable adjustment while the companies get the economics right; let's be honest: most broadband companies didn't do a good job judging network usage and layout. They're trying to make new decisions based on the past 4 years of experience, and they'll make more mistakes; but I'm guessing that it will be a better take this time around.
And, also, with all the outcry over raised rates, I don't see anyone mentioning that Several Broadbrand providers DROPPED rates (I'm biased, 'cause I work for Covad, and we dropped ours, but we're not the only ones). It's not ALL bad news.
In the long-run, I expect that broadband will remain unmetered (because, let me tell you, the metric captures are a pain-in-the-ass), but you'll see finer-grained pipe structures: for instance, you may have a 400kbps service for $30, 800kbps service for $40, 1.5Mbps for $60, and 5Mbps for $100, rather than a single 1.5Mbps service for $50. It's a far easier way to segragate the "hogs" from everyone else, and gets them to pay more for the service they use, but not unfairly limit them.
Bottom line here: don't like the service or support you're getting? Vote with your feet and dollars - use something else. There is ALWAYS something else these days, even if it's not what you expected.
Remember the article the other day when we all laughed at the Wilkes Barre IT guy who stopped the IBM maintenance on the AS/400 ? Well, this is the same kind of thinking: penny-wise and pound foolish.
Remember: support contracts are a form of insurance. They insulate you from the risk associated with the issue at hand. When looking at any form of insurance, you have to take into account what the worst-case senario is, and if you can handle it. In your case, the scenario is that you have multiple desktop failures, including critical failures of important machines (ie, severl of your main developers). Do a cost analysis: if I do a roll-my-own machine, what's the cost of it breaking? How much does it cost for that developer to have no (or a seriously inferior) machine for a week or more, vs. the 1 or 2 days a supported machine would be out?
For small companies, (especially those heavy in software development) I can't imagine a situation where the TCO of a fully-supported system is worse than a roll-your-own box. None The downtime and IT personnel time alone will kill that equation. For huge companies, it may pan out, but for a 60-desktop company with 1 IT person? Not a chance.
You need to put this into perspective with Management. Once again, they are looking at only the up-front costs, and none of the hidden costs, which in this case are the majority. Explain to them what the true cost of a desktop is, and how NOT buying a supported machine results in a WORSE return over the next year.
Now, here's a couple of recommendations for getting SUPPORTED desktops into your organization while not breaking the budget and still meeting increased performance needs:
ADD RAM TO THE EXISTING BOXES If any of the machines have less than 256MB, upgrade them immediately. This is extraordinarily cheap, and eliminates the primary performance problem of most machines. For the developer's, have them look at their RAM usage a couple times each day (using Task Manager, for simplicities sake), then consider if they need extra. Probably 512 in their machines will be sufficient.
Talk to a local PC shop. Many times, a local shop will be willing to take over support for you, in addition to an upgrading contract. They're a good source of manpower, and can even get you a loaner machine faster than Dell, et al. And, you can probably get them to upgrade certain machines you have AND officially support them!
Replace ONLY those machines who #1 doesn't solve the problem. Very, very little stuff on a desktop is CPU-bound. I run a 350Mhz P2 w/384MB of RAM on my desktop. I'm not a developer, but do Power-User Windows + Sysadmin. My machine runs fine with the following apps all open: two JDK 1.1 GUI apps, Oracle SQL+, SQL Builder, Outlook, Remedy, 3 PuTTy windows, 6 IE windows, Excel, and Word. I'm never CPU-bound. The only real jobs that need CPU are compiling, debugging a running app, and hard-core media dev (super-Photoshop, Flash, Dreamweaver...) I'd be surprised if more than 25% of your staff really, truely can justify something better after the RAM upgrade.
After upgrading, sell the extra computers. See #2 for a nice place to sell older computers.
I don't mean to harp on you personnally, but this kind of thing is why IT has a long, long way to go before being really professional. Folks, this isn't a garage. IT folks need to quite thinking like it's an expanded hobby, and also need to remind the Executives of this, too. It's a Profession, not a Trade.
-Erik
Systems/Network Architect and former SysAdmin
OK, OK, the articles are over at ZDnet, which should be the first clue (I mean, when was the last time you read an incisive, researched, and intelligent article over there?)
Get this folks: IBM is a SERVICES company. Lou made the right transition in the early 90s: IBM makes its money on selling expertise and consulting, not in pushing hardware. Even the more lucrative hardware divisions (Lexmark, the Mainframe group) pale in compare to the money raked in by IBM Global Services and the other custom software/solutions groups. IBM sells services and knowledge; they incidentally sell hardware to promote the sale of the services, but it's not their primary focus.
Sun, on the other hand, is in the business of pushing boxes. The vast majority of Sun's revenue derives from sales of hardware. Sun has a software division whose purpose it is to promote the sales of hardware. Java is there so that Sun will sell more servers.
IBM has no incentive to buy Sun. IBM already sells a boatload of consulting and services contracts to people who have Sun equipment, so they wouldn't gain much additional revenue by owning Sun. In addition, since IBM makes hardware which competes with Sun's stuff, guess who gets the software contract when a client needs to integrate IBM equipment with Sun? That's right, clients go to IBM, not Sun. If IBM eliminated its UNIX hardware (which, if they acquired Sun, would slowly happen), well, all these nice integration contracts would dry up.
IBM and Sun will never merge - there is absolutely no reason for IBM to be interested in Sun - in fact, they gain MORE by having Sun be a competitor on hardware. Sun and IBM really play in different spaces, and there is little if any synergy or logic behind a merger.
First off, run, do not walk, do not pass go, straight to the base/department legal department. Do not attempt to do ANYTHING until they OK it - the regulations surrounding secret-level work are inordinately hairy and convoluted, and only a lawyer specialized in classified-work law can answer your question definitively.
The other note, which is useful when discussing this with aforementioned lawyer: any work done under a Classified label (or higher) has different rules than "normal" work. Basically, any license that gets applied to the code only applies to those with a clearance at least as high as the code was written. Thus, if your code is Classified, I don't care if it has the BSD license, GPL, Bob's SuperFree License, or whatnot. Anyone without a Classified clearance isn't entitled to see it. Period.
This is a case where the murky grounds of National Security trumps Copyright (and other Intellectual Property) law. The law still holds, but it's restricted to the circle of security it's at.
National Security law basically allows you to use anybody else's code, provide you compensate them in a just and reasonable manner. As far as I've experienced, this means that you have to pay them the basic asking price on the free (i.e non-classified) market, and they don't get to say "no, you can't use it". For GPL/BSD/Open Source licenses, the asking price is Free, so well, they've been "compensated" as they've normally would.
In this case, Classifed work can certainly suck in Open Source code and not release it until it gets unClassified. And, as a side note, there is no "leaking" - people are not entitled to distribute code to non-cleared people, so it's not like Trade Secrets. It stays locked up until it's declassfied.
More than anything else, I'm looking for a ruling somewhere, somehow that manages to draw nice lines around where a program starts and ends for copyright and patent purposes.
We have APIs, libraries, modules, remote function calls, socket connections, pipes, shared memory, and a whole host of different ways in which code A communicates with code B. What we really need to define in a legal sense is exactly what constitutes a "program" for the purposes of code use. I definitely want to be able to isolate code which can potentially restrict "my" code's licensing (whether through a patent, restrictive copyright, GPL, or whatever). Until we get a good definition of what is "external" to a program, this will remain a legal quagmire.
Honestly, it's a hard decision. But it needs to be made. And the sooner, the better, for all parties: Free Software, Open Source, and Proprietary.
-Erik
The fundamental mistake of the 1996 Telecom Act...
on
FCC's Powell On Monopolies
·
· Score: 3, Insightful
... was not to open the local areas to competition (as the BabyBells and their ilk claim which slows "progress"), rather it was the institutionalizing of the monopoly on local infrastructure by what was in effect a giant telecom company.
Fundamentally, the only really decent way to fix things at this point is this:
Force the spin off of the local physical plant into a seperate company. That's right. split the Bells into a telecomm and a wires company. Give the wires company complete ownership of everything from the local CO to the customer. AND FORBID THEM FROM DOING ANYTHING ELSE BUT RENTING THEIR WIRES FOR SOMEONE ELSE TO USE.
Presto! Everything is solved! The local wires company takes care of all maintenance, has no incentive to prefer one telecom player over another, and will invest in upgraded technologies if someone wants it. Even better, this type of company is easily stimulated by government legislation to put in infrastructure where it might otherwise go (e.g. "We'll give you $100 per line if you wire areas with less than 10 people per sq mile" - that's how we got the country wired for telephone).
The Bells and all the CLECs then get to slug it out on a more level playing field (where the Bell's size does lead an advantage, but no more so than granted anywhere else in business).
While the Bells own the local infrastructure, it's always going to be a battle. It's not one which we have to fight. And frankly, this is such an obvious thing to do that other than hard-core lobbying by the Bells, there is no sane reason NOT to do it.
-Erik
Disclaimer: I work for Covad, a competative DSL CLEC.
Slashdot Mirror
The original article (and the subsequent followup) attempt to solve a problem using a desired tool, rather than looking for the right tool for the job. A lot like the old saying "If all you have is a hammer, everything starts to look like a nail."
The base problem that I think he's trying to solve here is that software quality is abysmal. That is, all commercial (and most free/open) software is riddled with bugs, many of which are well-known at ship time, but haven't been fixed.
Making source code available (whether as Open Source, Free Software, or a eyes-only copy-restricted) is orthagonal to this problem. yes, maybe, it could help. But that's incidental to the Free/Open software movement. And (as many people have pointed out), there are many problems with providing source with all programs, most of which are massive barriers to any help with quality of the software.
The fundamental flaw here is that commercial software's quality is the producer's responsibility, not the target audience's. In Free/Open software, the developers and audience have significant overlap, so it can be truly said that the audience can help quality. This is patently untrue for closed-source programs: the development community is very tightly controlled, and the user community has no real method of influencing quality (other than by not buying the product), even if provided with the source code.
So, this leaves us with the case of how to make the developer's produce better quality software. Fundamentally, we do this the EXACT SAME WAY all other industries insure minimal quality control: LEGISLATE IT. There are oft-quoted sayings about "if the car companies built cars like software companies build software..." and others to that effect. They all point a massive discrepency in the legal status of software: it doesn't play by any of the traditional product-liability and quality-control laws that every other product industry abides by. Yes, that will change the nature of the software industry: that's the point. And NO, it will not harm Free/Open software (as gifts - i.e. giving away something - are not coverd bty under the various product-liability laws)
You really want to fix the software quality problem? Require that software companies have a warranty of fitness. Require them to refund money for defective products (opened or not). Make them liable for damage caused by known defects. In short, treat them like anybody else. Software isn't special. It's time the software industry grew up.
See my previous post on why the software industry should quite being treated like a spoiled teenager.
The problem is real. The solution provided by the article is wrong. I'm right.
:-)
-Erik
First off, these are my experiences based on looking for a job in 1993 in Boston (which was right before the tech boom, and at the tail end of the early 90s recession). This should be generally good advice, but I can't speak to its effectiveness outside a major metro area.
I lived and worked in Boston for 7 years professionally, never making more than $40k. In fact, I started out at $27k, and usually worked 70+ hours/week for the first 3 or so years. I lived in my own apartment, and paid all my bills without going into debt. It's not really that hard, you just have to be careful and put off anything not completely necessary (like buying a new car, going on major vacations, good furniture, et al), and consider your first couple of years as an apprenticeship. Learn how businesses are run, and suck up all the experience you can. That will give you much better leverage to move upwards around 2006 or so, to a job with less hours and probably twice the pay you started with in 2003. And employers will be willing to pay it then, as you've proven yourself. 10 years after graduation, I now make well north of $100k, and consider it the payoff for being overworked/underpaid for much of my 20s.
Best of luck.
-Erik
Realistically, what you should be after is a completely open Network Acceptible Use Policy decision process. All users should be able to involve themselves in this process (students, faculty, administration, IT staff). During this process, the different groups will bring different desires to the table, and then be able to hash out an acceptible solution for everyone.
Realistically, there will always be some restrictions on what is considered "proper" network usage, since network bandwidth is a limited commodity. By having an open NAUP process, everyone has the chance to fully understand the limitations required, and contribute to the policy.
My suggestion it to propose an NAUP "board" with a representative from the above groups responsible for writing and approving such a policy. They should have the power to create and enforce such a policy, and the power to deal with any reprocussions thereof (e.g. if more bandwidth is needed to support the desired features, levy a fee on the appropriate user base).
-Erik
Last questions first (in reverse order):
1) Laws don't Prevent anything. They assign penalties for certain actions. As such, they serve as stimulus to modify behavior. You shoudn't be looking to prevent someone from doing something using the law. That's the trap we're in now - the only way to prevent a potential "bad-guy" from doing something is to lock up everyone, good and bad. If they're copying your program without buying the appropriate number, they've broken the law, and you're entitled to damages.
2) Quality laws do fine now for both the small guy and big guy. Both have to adhere to the same level for making suring that the quality is there. I'm not going to cut my local store more slack for selling me shoddy merchandise than I would WallMart, simply because the local store is "smaller". Obviously there has to be a certain amount of leeway for QA in software (i.e. it can't be perfect, but...). There has to be a minimal barrier-to-entry for producing software, and QA is it. Everyone is held to the same standard, and if the standard is written correctly, then it won't be too burdensome. However, you might need product-liability insurance, like many traditional manufacturing busineses...
3) This goes back to the original statement: you need to be able to provide them with a method for returning the merchandise, but you generally don't have a guaranteed method of locking out cheaters. As a rough analogy: what prevents me from buying a 42" TV, using it for a party that weekend, then returning it on Monday? I'm cheating the retailer, but that's not really detectible. The vast majority of people will pay for a properly priced product, rather than cheat. And if you do it correctly, someone with an "illegal" copy isn't going to be able to get upgrades, support, documentation, et al. And yes, part of your company will have to deal with maintaining serial number collections. That's part of the business. TANSTAAFL.
Right now, being a software company (both big and small) allows the company to sidestep a huge number of obligations that non-software companies take for granted as a cost-of-business. I see no reason for this, and in fact there is a considerable social cost to absolving the software companies of these responsibilities. If this reduces the number of potential small software companies starting up, then so be it. We have to get out of the mind-set that a software company can just spew random crap at the EU. There has to be some responsibilities with producing a product, and these responsibilities cost money.
-Erik
Somehow, the technology sector was promoted (and believed) to be "different" than any other sector in history, and therefore we couldn't, possibly, no never apply the same logic that we'd used to analyse other sectors at it. Look where that attitude got us.
I'm not saying that we shouldn't look at technology with fresh eyes as to the benefits and possibilities it brings. And I'm definitely not for forcing all technology into previously-defined cubbyholes via direct legal analogy (e.g. it's the Internet folks, not some fucked up mutant telegraph or road system. Look at the new paradigm). However, that doesn't mean we can't learn and use previous analytical and legal tools to help mold the direction of tech.
I'd actually love to see a good chunk more of regulation in the "tech" sector, which actually also includes the "Intellectual Property" sector. We really could use:
Tech needs to stop with the "we're special" attitude, and get back into the real world. This includes getting a bunch of regulation and responsibilities. Right now, the tech sector is behaving like a spoiled teenager. The sooner it grows up and realizes it needs to play by the same rules everyone else does the sooner that politicians (and everyone else) takes it seriously again.
-Erik
... or don't we see chipset manufacturers avoiding the hard problems completely? I realize that cost is an issue, but for the most part, we're talking about high-performance workstation and server boards, which cost $500+ or more.
The biggest issues these days are:
Unfortunately, there seems to be little innovation going on in chipsets these days. The high end looks very, very, very depressingly identical to the cheap consumer crap. WTF folks?
-Erik
which are:
Unified System Documentation I want all docs in a single, standard format that all programs must write their basic documentation in. No more man, info, html, pdf, ps or whatnot. I'd prefer a fixed SGML DTD (docbook is OK, but I'd prefer a designed-from scratch one specifically to address the system documentation target). That way, we can can get good viewer independence with modern features (hyperlinks, fonts, in-line graphics). All of the current formats are lacking in at least two areas, and we don't have agreement on which to use. This is a big place for them to step up.
Standard Config Files No, this is not a request for a Registry (the merits thereof are for another discussion). What we want here is to get rid of the 80 billion different ways to write a config file. I'm sorry, but they all should be a nicely tagged XML (or similar) file nowdays. It sucks to have to figure out the idiosyncrasies of the various config files. This issue isn't simple, but is definitely a place where a good discussion is needed.
-Erik
I can't give you specifics, because they depend on the field you're looking to enter, and more importantly, the details of the job, which vary widely. I hope the general descriptions above help.
Contact me directly if you want to talk more.
-Erik
Systems Architect
...this actually looks like a very useful tool. Originally, I was going to write it off as another feel-good kowtowing of the modern world to kids' micro-second attention span, but the article actually makes it sound truly useful, especially the parts where they find it helps Mom and Dad who don't speak English as well as they would like.
I'd even go so far as to say that it can replace a major chunk of "homework" for these kids. Even better, it seems to eat up time normally occupied by traditional video gameplay, which is basically useless (other than purely mindless entertainment). All-in-all, sounds like a good thing.
My sole complaint here is this: the more we try to package learning as entertainment, the less we seem to emphasize that learning for its own sake is fun and interesting. And we also seem to be reinforcing the concept that it has to be FUN in order to be worth doing. Sadly, the world doesn't opperate this way, and I think we're doing a great disservice to kids if we get them thinking that learning has to be somehow immediately entertaining.
I realize this is for younger kids, where we don't have this problem so much, but I want to make sure that at some point, we start reinforcing the notion that learning for knowledge (and problem solving) are their own rewards, and don't have to be wrapped up in some entertainment package to be worth doing.
-Erik
To have a "succesful" voting system, there are several important criteria to accomplish:
Satisfaction on all accounts is difficult, and not just for electronic systems. Most current systems fail considerably on at least one of the above requirements.
The sad thing about this boondoggle is that there is a relatively good solution that can be made into a great solution with a little effort, but people seem to be ignoring it:
1920s-style mechanical voting booths
These booths are designed to mechanically prevent incorrect voting (e.g. you can't flip the level for multiple people for an office, unless specifically allowed for that election), they hardly ever break (and if they do, it is readily apparent to the voter in virtually all cases that something is wrong), they leave a mechanically punched card with the voter's actual vote on it for later recound (none of those stupid hanging chads with a mechanical puncher), and they provide a quick summary of the running total of votes on the back via odometer-style readouts. The voting itself is clear, as the voting panels tend to be large with lots of space for names (and even pictures), and a small lever for voting immediatly overtop of the candidate (e.g. if you vote for a candidate, the lever covers the person's name/picture).
Voting booths aren't perfect - you still need a good voter registration system, and an automated vote-reporting mechanism to report votes back to a central location would be good, but the overall solution is far superior to anything I've seen proposed so far, except in one aspect: price. Nobody makes these machines anymore, and they are large mechanical items which would most likely cost $10k or so each. But they last forever (I mean, I voted on one at home in 1990 which was made in 1934). What's the life expectancy of some of the proposed electronic machines? 10 years, maybe?
There are good solutions out there. We just have to look for one, and not be trapped by assumptions about how it must look.
-Erik
First off, all the suggestions in the post above by chrismcc (here) are excellent. I am going to expand on them a bit.
First, you really should have an AS number and get a dedicated IP allocation from APNIC - it will be immensely useful, and save you a whole bunch of money and headaches in the future. There are some upfront fees (I just checked, and a /19 (32 class C) runs about $8192, with an AS number cost $500, both of which are one-time fees, and you don't have to be an APNIC member), but they're well worth it, and not excessive.
After you get the AS and IP block, talk to your new ISP and your old ISP. Advise them that they will need to be advertising your AS now.
If you don't already have it, upgrade all your border routers to support BGP, so you can actually use the AS number, and also so you can potentially use multiple different ISP pipes for redunancy and load balancing. Depending on your setup, this might cost some money. However, given your setup, I suspect that you don't have anything more than a Cisco 3600-series border router, which is fine (and the BGP upgrade isn't very expensive).
Using the new APNIC address block and AS number, number all your network equipment with the new IP space, keeping the original IPs from the old ISP in place.
Have the new ISP begin advertising the AS number and your new IP block. Do some testing from outside to make sure you can reach all segments of your network.
For all important machines and equipment (primarily servers, but stuff that generally retains a static IP), give them a new IP. Almost everything supports virtual interfaces now, so it's trivial to have two different IPs assigned to the same machine these days.
Do some more testing, to check that you can reach these machines via the new IP (do both internal and external testing, as required).
Update DNS to include both the new and old IP for all assigned machines. Change the TTL to something VERY LOW, like an hour or so.
Test DNS starting the next day, and do repeatedly for the next 3-4 days.
Update any servers providing DHCP or BootP or similar dynamic service to provide IPs from the new block. Continue testing.
After about a week of running both the new and old DNS entries in parallel with all machines assigned a NEW IP address, consider removing several of the DNS entries for the old IP space. Do this, and check to see if anything breaks. Fix it.
Remove all old IPs from DNS. Wait a week or so to see if anything lingering breaks, and see if you get any reports from outside as to problems.
Remove all of the old IP numbers from all machines and network equipment, and notify the old ISP that you have completed renumbering, and that they should change routing so that IP space no longer points to you. Inevitibly, you probably will run into something you missed. Fix it.
Ditch the old ISP, or keep them for redundancy/load balancing, but make sure they're publishing your AS number and new BGP information.
Many of these steps above will require coordination with your client companies. However, if you do it right, there should be NO DOWN TIME, and the transition will be transparent to your clients.
-Erik
- DOJ crawls through the P2P networks, scanning your file swapping list, and arresting everyone it can find which they believe is illegally sharing copyrighted materials. They prosecute a buch of big-time file-sharers, winning some, losing others. But they get enough that it scares most people.
- The big P2P sharers leave the networks. Usage drops drastically. However, the P2P software makers are still in business, as they are now left alone. Music is still being shared, only now its stuff that explicitly has been allowed by the Artists to be shared.
- Now that the P2P network isn't clogged with NSYNC tunes, people actually can find (and listen to) stuff that isn't on ClearChannel or the other big chain Radio stations. Bands have small successes - releasing 128Bit MP3s to the P2P networks, and selling 256Bit ones on their websites for a couple of dimes. It becomes possible for a regional band to make a few tens of thousands of dollars of MP3 sales per year (100,000 sales @ 40 cents each adds up), and people start to flock to the P2P networks again.
- Big-time artists notice it. Those which are in controll of their catalogue (through foresight, ownership of their label, or lawsuits), decide that its possible now. Somebody big tries it, and makes a couple million in sales on their back-catalog in the first month. The artists drool, as they see 75% profit margins on per-MP3 sales, with nothing going to the label (or other middlemen).
- Artists flock to the P2P networks to sell their songs, and the big labels are reduced to what they really are: promotional marketing houses. Artists contract with them for fixed fees (or precentages of gross receipts) to do promotion and such, and label no longer get ownership of the music, as Artists now have the means to say "Fuck You" if the label demands it.
I'd love to see this scenario, and I think it's realistic given two BIG "ifs":- IF they really start to clamp down on the big P2P users with huge illegal catalogs, so we can get all the infringing crap off the P2P networks. Once it's all legal and above board, you can start running real marketing analysis and do the business case studies that you need to make it a real sales market and distribution channel.
- IF the artists continue on the current road of fighting to get ownership of their music. If they quit (and continue with the Faustian bargain of their soul for 15 minutes on MTV), then it's over. I'm hoping they have the backbone to stick it out.
And realistically, isn't this what we want? P2P networks with LEGAL music for us to try out and see what we want? And an economically viable way for the artists to produce music and get paid for it in a reasonable manner?Call it what you want, but sharing copyrighted MP3s right now is definitely illegal, and in the long turn, harmful to everyone. Don't do it - it's NOT the Right Thing.
-Erik
Together, Russia and NASA can come up with a good design for a Mars-mission vehicle. Unlike the Space Station (ISS), there are a huge number of unknowns which would have to be dealt with, and consequently, novel innovations for them cooked up (we got a huge amount of cool stuff out of the space program from the 60s, but nothing really interesting in the 80s and 90s). Here's a short list of totally new problems which would need to be solved:
NASA really needs a kick in the pants. Unfortunately, that requires some leadership and real vision from the President, and we haven't had that kind in awhile. They really should relegate the lift capability to private industry and just concentrate on making the Mars ship.
Oh well. Maybe someday...
-Erik
Given the technological design behind SSL (in that it operates immediately above IP, and below TCP/UDP), the summary you provide above is true.
That is, you can set up a cluster of web servers behind a typical redirector. Say Server A, B, and C. Each machine has a different IP address, which is a routable address (let's call it w1.foo.com, w2.foo.com, w3.foo.com). There is a single IP address for the "master" domain (say www.foo.com). All machines are set up to serve www.foo.com, both HTTP and HTTPS. For normal HTTP requests, the redirector does it's thing, with EACH http request coming to www.foo.com being served by the next available machine. Any connection a client makes can potentially be served by any machine.
However, since SSL operates below the TCP/HTTP header, a client making a SSL connection to https://www.foo.com will initially be load-balanced across the machines. However, for the rest of that SSL session, it will continue to communicate ONLY with the machine which initially answered the beginning SSL connection.
This isn't a real big problem for most web apps, since each connection is really just getting a bunch of web pages. If the server goes down, you simply have to push RELOAD on the client, and it re-initiates the HTTPS session, getting another machine to answer. It can be a serious problem with other SSL apps, as the termination of a session by the loss of the answering machine may make it difficult to programatically re-start the session.
Just to make this clear: each time a client initiates an SSL session, it gets bound to a single server. This server may be different for each session, but remember that a "session" may include many data requests.
There is no problem sharing certificates between multiple machines (as the cert is tied to hostname, and it's easy to duplicate across multiple web servers). It's an SSL protocol limitation.
-Erik
There are really three seperate categories you get into once you're considering moving data from primary storage. You seem to be asking about the first, but I'll cover all three for completeness.
Near-line (a.k.a secondary storage)
Primary storage almost always consists of the fastest hard drives directly attached to your data source (file server, SAN, workstation, whatever). Historically, near-line has been some medium where the end-user could access the data required in the same manner as primary storage, but at a slower rate. The old solution used to be either a different server using older/slower disks, or an RW optical jukebox. Near-line storage almost always is very high read-usage, but the occasional write isn't unlikely, so you generally want a media that can support writes.
Backups (a.k.a. save-your-ass storage)
Backups are a place to temporarily save data in case of an emergency. The criteria generally don't include re-writability, but do concern with ease-of-access in the case of a recovery. In addition, Backups expire - after a certain period of time, the data is no longer available. Tape has been the choice for this for a long time, with it's high storage capacity and low cost. Higher-end solutions have been the "on-line snapshot" capabilities of SAN and NAS devices (essentially to make a static mirror of data on extra storage space). CD-R and even floppies have been popular for the low-end. Whatever the choice is, the main concern is reliability, and the ability to backup the data within a set time window.
Archival (a.k.a save it for the history books)
This is a big one, and one frequently misunderstood. The two major criteria for Archival purposes are Survivability, and Retrievability. That is, the solution has to make sure it does NOT degrade with time (i.e. it doesn't introduce errors after sitting on the shelf for 20 years) and that you will realistically have a method to retrieve the data over it's lifetime (e.g. are they still going to have devices that can read your data media in 30 years?) Magnetic tape is a BAD THING for Archival purposes, despite its common usage. It fails on both tests. Mastered CDs (NOT CD-R) and Optical Disks are generally the preferred method here.
In the modern world, I would recommend a backup server using RAIDed IDE drives for Near-line these days. The relative cheapness of IDE drives, combined with the newer IDE RAID cards provides an unbeatable cost/storage/reliability ratio (far superior to CD, DVD, Tape, or Optical Disk), and it's by far the easiest to maintain and use, since it's simply another fileserver. Don't scrimp, however. A good one of these should probably run $3-$4k with 8-10 100GB drives, redundant power supply, and hardware RAID.
Backups are a bit more complex, and the variables make a one-size-fits-all recommendation unrealistic. And you didn't ask for that anyway, so I'm not going to make one. :-)
Archival really means you want to keep (or are required to keep) the data around, but don't need access to it much. If you don't intend to keep the data for more than 15-20 years, you can probably get away with CD-R. Otherwise, look into having your data pressed onto CD (i.e. real mastered CDs). They last a good 100 years or so, and it's relatively cheap. In either case, you want multiple copies of each disc, and the good-old CD-jukebox is your friend.
As you imply (and other posters have noted), DVD-R/RAM/RW/+RW isn't quite stabilized yet. Despite their larger capacity, I wouldn't change the above recommendations, other than replacing CDs with DVD when it settles down - DVD mastering isn't anywhere as cheap as CD mastering is (and if you do master DVDs, make sure that you specify UNENCRYPTED DVD so you don't get CSS put on accidentally).
As a side note: there's a whole industry built around Hierarchical Storage Management (HSM) which deals with automatically moving data between the various storage levels, and recovering it as need be. It's a bit beyond what you describe you're looking for, but look at one of the big UNIX storage players' (Sun, HP, IBM, EMC) site for a whitepaper on it. They're a good read for concepts which you can apply, even if you're not using their multi-million-dollar hardware/software packages.
Best of luck.
-Erik
I've read the proposal that passed the European Parliament, and if the policy the Bush administration is attempting to put in place is similar, then it won't pass Constitutional muster. It fails on at least three major points:
I don't think they really realize the volume (either the US or Europe) as to what they're requiring, either. A rough estimate is that an email header is 1k, and that a log of an http request is .5k. For an average user, 1000 http requests (remember, each picture/icon is a new request) and 10 emails per day would be typical. That's about 500k per person per day. For a mid-size ISP with 10,000 users, that's 5GB per day, 1.825 TB per year. Even assuming good compression of 90%, that's 180GB per year. Given that you would need to get a good machine and lots of redundancy for it (remember, this is a LEGAL requirement), I can easily see it costing $30k PER YEAR or more for the hardware alone for log space (plus the additional costs to upgrade the routers/mail servers/proxies and other infrastructure to allow for such vast logging in the first place). I'd estimate that it would be at least triple that, when all other factors are included. Even a $30k capital expenditure per year is a pretty good chunk of change for a company with a probable revenue stream of $3M per year. That's a 1% value of gross receipts (conservatively). And what about someone like Earthlink or similar, who has millions of customers? You're looking at requiring Terabyte storage systems costing multi-millions of dollars.
Even though I've seen some really dubious legislation and policies over the past 10 years (e.g. DCMA), I don't think this one will fly.
-Erik
You're confusing some of the performance characteristics of the ATF (which turned into the F-22 Raptor) with the JSF (the now F-35).
The F-22 is a high-performance, air-superiority fighter intended to superceed the F-15. It has a 2nd-gen stealth (very low radar cross-section and low observability infrared/visible features) design, coupled with a high speed (~ Mach 1.4 without afterburners, ~2.2 full burner), and is primarily a missile-platform (ie, no bombs). It is the premier air-superiority fighter in the world.
The F-35 is a ground-attack AKA strike fighter (NOT a close-support aircraft). It tops out at about Mach 1.5 or so at altitude, and is not anywhere near as stealthy as the F-22 (though much, much better than the F-16, F-15, or F-18). One version will have VSTOL cabilities. It carries laser designators and other ground-attack sensors, and has a modest bomb-load (though smart weapons will be it's primary payload).
All things said, the F-35 is a good design, and a reasonable compromise on cost, performance, and advanced technology. HOWEVER, it is NOT an air-superiority fighter (though the Royal Navy will use it as such off their carriers), neither is it a dedicated close-support aircraft (though the US Marines will use is in such a roll). It is primarily a multi-role strike craft. It's really a blend of the features of the F-18, Harrier, F-16, and F-22, with some compromises.
The A-10 will probably remain the best close-support aircraft around for general use (the Harrier and similar craft are superior, but only in specific uses), and the F-15 and F-14 (and of course the F-22, plus the MiG-29) are better air-superiority fighers.
My major concern with the F-35 is the low payload cability compared to the F-16/18 (though it's superior to the Harrier). It's probably OK, since it looks like the "bomb dumptruck" role of massive dumb firepower is being relegated to the B-52 bomber and AC-130 gunships these days.
-Erik
I'd have to say the most "expensive" bits of information had to be the notes that Klaus Fuchs passed from the Manhattan Project to the Soviet Union. Estimates I've seen are that the material was no more than four dozen full pages, but that material was the key to allowing the Soviet Union to finish their Atomic bomb research years ahead of time (providing at least a 5-year jump). For an estimate of what the Manhattan Project cost, look here. For a conservative estimate, I'd say that those 50 pages (~2000 characters each = 100kB) saved some $10 Billion in research costs. And that's in 1945 dollars.
The German, Italian, and Japanese cypher codes were similarly valuable, though not quite as expensive to obtain.
Historically, I'd say that the $50 in trinkets that Dutch explorers paid to the Native Americans living on Manhattan Island for title to their island (ie, for the signature on the treaty giving the Dutch what became New York City) was the ultimate rip-off (or, great deal, depending on which way you look at it). Signature = ~25 bytes, with current value of the Manhattan Island real estate well north of $10 trillion.
As a side note, the US (and presumably the other nuclear powers) does NOT maintain the "Launch Codes" at the political level. These are AUTHORIZATION codes, which tell the military that a valid order to launch exists. The military maintains the actual launch codes (at different places for different weapon systems), so theoretically, it is possible to launch a nuclear weapon without permission. For obvious reasons, the military designs launch systems so this is as difficult as possible.
-Erik
Specifically, he's limited his view to the programmer who works for a company which is in the business to sell software. That is, where the company makes its revenue by the sales of software to someone. In that case, the programmer is the primary revenue-producing asset of the company, and there are significant reasons why Open Source isn't always the best way to do things in this market segment. In fact, I would argue, that for software-only companies, Proprietary is the best way to go for the vast majority of them. Not all, but clearly, most.
However, what he fails to understand is that software companies are at best a vocal minority of companies which produce software. Virtually all Fortune 1000 companies have staffs of in-house programmers writing custom apps. ALL government agencies have them. Hardware companies (or those whose primary interest is in selling PHYISICAL devices) have legions of programmers whose sole purpose is to cook up neat programs which help them sell their hardware. Even people such as IBM global services sell contracting time/expertise, though they produce significant software for their clients.
This second category is where Open Source makes the most sense, and where I would argue will eventually smother Proprietary. Sure, I can see companies (and organizations/governments) buying Proprietary software from the software-only companies (because it's cheaper/faster/easier to get it from them right now), but I'd expect that the mid-term results of going totally-Open Source for all code produced by them will win.
So, to quote from Return of the Jedi: "...you're going to find that many of the truths we cling to depend greatly on our own point of view." The author may very well be right in the localized case, but I sincerely think he's wrong for the general one.
-Erik
..I always wondered how Canada could possibly have much lower rates than the US.
I know how much it costs to put in DSLAMS. I know what the monthly equipment space rentals are at Central Offices. I know what it generally costs to maintain the network infrastructure to support a DSL userbase. And, let me tell you, for $40/month, people like us aren't making huge profits (mind you, we do make money now, but not in the bucketfulls that people here seem to be implying).
Even considering being an ILEC vs a CLEC here in the USA, about the only way I can see the big Canadian DSL providers being able to provide such cheap service is through subsidizing them, either from their other (e.g. voice) businesses, or from the government (e.g. tax credits, direct payments, "access fee" taxes, etc).
Don't get me wrong - that's a perfectly valid way to deliver cheap broadband. The USA did it with Voice service. However, I'm not sure that's the best thing in the long run for Data. In the end, I expect that Voice and Data regulations here in the USA will converge (since there really is no sane reason for keeping them apart anymore). I'd rather see a bit less regulation than tying the whole data network up with the mess of voice regulations. (which isn't the same thing as the ILEC's want - they want voice and data to be UNregulated. Not a good thing either, so long as they control the physical last-mile).
Anyhow, the current price see-saws in the USA are an inevitable adjustment while the companies get the economics right; let's be honest: most broadband companies didn't do a good job judging network usage and layout. They're trying to make new decisions based on the past 4 years of experience, and they'll make more mistakes; but I'm guessing that it will be a better take this time around.
And, also, with all the outcry over raised rates, I don't see anyone mentioning that Several Broadbrand providers DROPPED rates (I'm biased, 'cause I work for Covad, and we dropped ours, but we're not the only ones). It's not ALL bad news.
In the long-run, I expect that broadband will remain unmetered (because, let me tell you, the metric captures are a pain-in-the-ass), but you'll see finer-grained pipe structures: for instance, you may have a 400kbps service for $30, 800kbps service for $40, 1.5Mbps for $60, and 5Mbps for $100, rather than a single 1.5Mbps service for $50. It's a far easier way to segragate the "hogs" from everyone else, and gets them to pay more for the service they use, but not unfairly limit them.
Bottom line here: don't like the service or support you're getting? Vote with your feet and dollars - use something else. There is ALWAYS something else these days, even if it's not what you expected.
-erik
Remember the article the other day when we all laughed at the Wilkes Barre IT guy who stopped the IBM maintenance on the AS/400 ? Well, this is the same kind of thinking: penny-wise and pound foolish.
Remember: support contracts are a form of insurance. They insulate you from the risk associated with the issue at hand. When looking at any form of insurance, you have to take into account what the worst-case senario is, and if you can handle it. In your case, the scenario is that you have multiple desktop failures, including critical failures of important machines (ie, severl of your main developers). Do a cost analysis: if I do a roll-my-own machine, what's the cost of it breaking? How much does it cost for that developer to have no (or a seriously inferior) machine for a week or more, vs. the 1 or 2 days a supported machine would be out?
For small companies, (especially those heavy in software development) I can't imagine a situation where the TCO of a fully-supported system is worse than a roll-your-own box. None The downtime and IT personnel time alone will kill that equation. For huge companies, it may pan out, but for a 60-desktop company with 1 IT person? Not a chance.
You need to put this into perspective with Management. Once again, they are looking at only the up-front costs, and none of the hidden costs, which in this case are the majority. Explain to them what the true cost of a desktop is, and how NOT buying a supported machine results in a WORSE return over the next year.
Now, here's a couple of recommendations for getting SUPPORTED desktops into your organization while not breaking the budget and still meeting increased performance needs:
I don't mean to harp on you personnally, but this kind of thing is why IT has a long, long way to go before being really professional. Folks, this isn't a garage. IT folks need to quite thinking like it's an expanded hobby, and also need to remind the Executives of this, too. It's a Profession, not a Trade.
-Erik
Systems/Network Architect and former SysAdmin
OK, OK, the articles are over at ZDnet, which should be the first clue (I mean, when was the last time you read an incisive, researched, and intelligent article over there?)
Get this folks: IBM is a SERVICES company. Lou made the right transition in the early 90s: IBM makes its money on selling expertise and consulting, not in pushing hardware. Even the more lucrative hardware divisions (Lexmark, the Mainframe group) pale in compare to the money raked in by IBM Global Services and the other custom software/solutions groups. IBM sells services and knowledge; they incidentally sell hardware to promote the sale of the services, but it's not their primary focus.
Sun, on the other hand, is in the business of pushing boxes. The vast majority of Sun's revenue derives from sales of hardware. Sun has a software division whose purpose it is to promote the sales of hardware. Java is there so that Sun will sell more servers.
IBM has no incentive to buy Sun. IBM already sells a boatload of consulting and services contracts to people who have Sun equipment, so they wouldn't gain much additional revenue by owning Sun. In addition, since IBM makes hardware which competes with Sun's stuff, guess who gets the software contract when a client needs to integrate IBM equipment with Sun? That's right, clients go to IBM, not Sun. If IBM eliminated its UNIX hardware (which, if they acquired Sun, would slowly happen), well, all these nice integration contracts would dry up.
IBM and Sun will never merge - there is absolutely no reason for IBM to be interested in Sun - in fact, they gain MORE by having Sun be a competitor on hardware. Sun and IBM really play in different spaces, and there is little if any synergy or logic behind a merger.
-Erik
First off, run, do not walk, do not pass go, straight to the base/department legal department. Do not attempt to do ANYTHING until they OK it - the regulations surrounding secret-level work are inordinately hairy and convoluted, and only a lawyer specialized in classified-work law can answer your question definitively.
The other note, which is useful when discussing this with aforementioned lawyer: any work done under a Classified label (or higher) has different rules than "normal" work. Basically, any license that gets applied to the code only applies to those with a clearance at least as high as the code was written. Thus, if your code is Classified, I don't care if it has the BSD license, GPL, Bob's SuperFree License, or whatnot. Anyone without a Classified clearance isn't entitled to see it. Period.
This is a case where the murky grounds of National Security trumps Copyright (and other Intellectual Property) law. The law still holds, but it's restricted to the circle of security it's at.
National Security law basically allows you to use anybody else's code, provide you compensate them in a just and reasonable manner. As far as I've experienced, this means that you have to pay them the basic asking price on the free (i.e non-classified) market, and they don't get to say "no, you can't use it". For GPL/BSD/Open Source licenses, the asking price is Free, so well, they've been "compensated" as they've normally would.
In this case, Classifed work can certainly suck in Open Source code and not release it until it gets unClassified. And, as a side note, there is no "leaking" - people are not entitled to distribute code to non-cleared people, so it's not like Trade Secrets. It stays locked up until it's declassfied.
-Erik
More than anything else, I'm looking for a ruling somewhere, somehow that manages to draw nice lines around where a program starts and ends for copyright and patent purposes.
We have APIs, libraries, modules, remote function calls, socket connections, pipes, shared memory, and a whole host of different ways in which code A communicates with code B. What we really need to define in a legal sense is exactly what constitutes a "program" for the purposes of code use. I definitely want to be able to isolate code which can potentially restrict "my" code's licensing (whether through a patent, restrictive copyright, GPL, or whatever). Until we get a good definition of what is "external" to a program, this will remain a legal quagmire.
Honestly, it's a hard decision. But it needs to be made. And the sooner, the better, for all parties: Free Software, Open Source, and Proprietary.
-Erik
... was not to open the local areas to competition (as the BabyBells and their ilk claim which slows "progress"), rather it was the institutionalizing of the monopoly on local infrastructure by what was in effect a giant telecom company.
Fundamentally, the only really decent way to fix things at this point is this:
Force the spin off of the local physical plant into a seperate company. That's right. split the Bells into a telecomm and a wires company. Give the wires company complete ownership of everything from the local CO to the customer. AND FORBID THEM FROM DOING ANYTHING ELSE BUT RENTING THEIR WIRES FOR SOMEONE ELSE TO USE.
Presto! Everything is solved! The local wires company takes care of all maintenance, has no incentive to prefer one telecom player over another, and will invest in upgraded technologies if someone wants it. Even better, this type of company is easily stimulated by government legislation to put in infrastructure where it might otherwise go (e.g. "We'll give you $100 per line if you wire areas with less than 10 people per sq mile" - that's how we got the country wired for telephone).
The Bells and all the CLECs then get to slug it out on a more level playing field (where the Bell's size does lead an advantage, but no more so than granted anywhere else in business).
While the Bells own the local infrastructure, it's always going to be a battle. It's not one which we have to fight. And frankly, this is such an obvious thing to do that other than hard-core lobbying by the Bells, there is no sane reason NOT to do it.
-Erik
Disclaimer: I work for Covad, a competative DSL CLEC.