I think, though, it's poor form for commercial entities to go ahead designing and releasing GPL based software without thinking ahead and accepting that they have to supply source code to their paying customers.
This is precisely the GPL tradeoff.
A lot of times a company can save itself some time and money by using an already-implemented GPL'd program. If a company goes this route, it pretty much has to define its product in one of two ways: hardware, and/or service.
Hardware company examples include Linksys (WRT54 routers), D-Link (Network Attached Storage devices), Sharp (Zaurus PDAs). I would be hard-pressed to call any of these companies 'hardware and service,' as they all pretty much release the hardware and then don't bother offering patched firmware (at least, none of them do it very often). They only make money off of the initial hardware sale, so they have little motivation to fix bugs -- especially when the community can do it for them.
Service companies include RedHat, Canonical, etc. Their bread and butter is selling you technical support and patch services, preferably every year. They do have a lot of motivation to give back to the community, precisely because if no-one else fixes a bug, their customers will walk away. Until recently, RedHat was probably one of those quasi-GPL-violators in my mind: the Red Hat Network was probably built using GPL'd building blocks, but the code was never released (until last week, woohoo!). Note my use of the word 'probably,' here -- I haven't gotten a chance to peruse the satellite server source code yet, I'm mostly speculating:).
Anyway, a company *can* make and save a lot of money by going with the GPL, so long as they fit one of those scenarios (or some other that I'm not thinking of). If a company wants to be a software license company, though, then the GPL is definitely not a wise choice;-).
I'm still a bit confused about it, but it seems like they have to provide the sourcecode for the entire thing, except for stand-alone proprietary programs running 'separately' from everything else, and provided they aren't using GPL libraries.
A lot of people do poorly. I take it once ever year or so. I just took it, and I got one wrong. I don't think I've ever answered it 100% rightly. Maybe next year;-).
It's funny to me, because I got modded troll on slashdot back in 2000 or so. I claimed that the NSA misunderstood an aspect of the GPL when they hired a contractor to work on SELinux (the contractor included patent-encumbered code in their implementation). People claimed that the GPL is so easy to understand and that I was an idiot, and also that the NSA could not have possibly misconstrued the legal ramifications of the GPL.
If only I could meet the legal geniuses that flamed me;-).
I'm glad to see that people are actually asking questions about the GPL on slashdot these days, instead of just assuming that they know how it works. It brings a tear to my eye.
Is the end-user - at a public terminal - entitled to the same rights under GPL as the owner of the computer on which the software runs?
Here's a very weird answer. No. This is a point of contention for a lot of people, myself included...
In the case of a public terminal, the 'user' (and by user I mean non-owner) technically never agreed to the the terms of the license. They don't 'own' the binary version of the program, they are just along for the ride. The GPL only stipulates that owners of a binary copy of the program get access to the code. Once they have code, though, they are free to give it away to their friends...
The bigger point of contention for people lately has been web services. If facebook uses a GPL'd web server (or even some GPL'd web service implementation like phpBB) and makes modifications to it, but never releases the binaries to anyone, it can still use that modified server to provide services to people. You only get to use the http interface to the server, not technically the server itself, and so you have no right to the code. Of course, if facebook doesn't do a good job with NDAs, any one of its employees could release the modified code to the world. Facebook may fire the employee, but couldn't sue them. Technically the employee didn't do anything wrong in this example (unless, like I said, Facebook made the employee sign an NDA or some other legal document beforehand that stated the employee would not share modified source code...then Facebook could sue their pants off for violating that agreement).
This whole shebang was, iirc, brought up in the early drafts of the GPLv3. It is hard to say what the right answer here is. I kinda lean towards the 'openness' side of the issue. I submitted a patch to the web server, and if a company modifies the webserver to suit their needs, I would love for them to be required to share their change with the world. The GPL is all about this flow of ideas. Companies, naturally, need to make a profit. If they tweak some software to provide a unique service, they want to protect their investment by not giving the investment away to competitors for free. I guess we'll see who wins in GPLv4:).
Sounds like you need to take the GPL quiz. This particular issue is addressed in Question 1 of said quiz.
Don't worry, you're definitely not alone in any misunderstandings of the GPL...lots of people think they understand all the legal aspects of it completely when they don't. I used to be guilty myself. Now I just don't claim to know everything about the GPL;-).
In "Surely You're Joking, Mr. Feynman," Richard wrote an anecodte about just this: he went to bars and tried to meet women, but they wouldn't sleep with him. Finally, he went to a bar one night and treated a woman like garbage: made her pay for the drinks, barely paid attention to her, etc. He scored. And it worked again and again and again...
Question: What would the penalty be if this was not a computer crime? Suppose he broke into the school's office and changed the grades records for several students?
One count of breaking and entering, and 34 counts of altering a public record? Would these even be federal crimes?
My mother teaches in a high school, and was talking about their new online grading system. She has to submit grades via the web service, and students are able to log in to the same web interface to read their grades. I asked my mother if the school kept other documentation of student grades (for example, if she had to turn in a grade book at the end of the year so that the university could compare the online version to her paper version). The answer was no. The high school relies completely on the online system for determining grades. This is accessible via the internet. The software is called Genesis Passport. Not a lot of information is available about it online, but I have to wonder if the thing could possibly be secure. I kind of doubt it, but what do I know, I'm only a professional security researcher and pen-tester...
I'd be quite happy if this is how DARPA advertises. I can't speak to whether or not it is, as I never worked for them. I can say that I now recall during my pitching ideas to a DARPA PM, he was essentially offering me a job, saying that if I ever wanted a challenging research director-type position, I should consider sending him my resumé. It was quite obvious from his pitch that it would be more manager-oriented. Perhaps some day I shall send my resumé in, when I am ready to relax my typing hands a bit;-).
I do know that the Air Force Research Laboratory (one of my previous employers), advertised to candidates that they did 95% of their research in-house. I actually asked to have read access to the AFRL time-tracker database before I left. Somewhere less than 10% of the time billed that year was spent on what is known as 6.1 ("Basic Research") funded projects. I know first-hand that this number was fudged a bit -- there were certainly projects calling themselves basic research that indeed were not. The rest of the time was charged to what are called 6.2 and 6.3 efforts, which are projects already under contract with a company (so program management, contract management). I did feel like I was lied to by the recruiters at AFRL, particularly that they asserted during their presentations that they were almost exclusively in-house research. They seemed to present an awful lot of projects as having been developed internally, when in fact they were researched and implemented by contractors.
I worked in the Space and Naval Warfare Systems Center, and they were about 10 million times better. Many department heads in that organization encouraged my efforts to do Real Research, and spent a lot of time helping me out. Mind you, they don't have Research Lab in their title. The folks at SPAWAR are awesome in this way. Ultimately, love and a lot more money took me into the private sector, where I happily work on some big problems and feel a lot more productive. I do regret leaving the fine folks in the Navy behind, as I think that work there would have evolved to be very much to my liking.
One big thing I learned from my time at both of these government positions was that interviews are extraordinarily important. My interview process lasted about 4 hours at AFRL, and did not involve any in-depth technical session. My interview process with SPAWAR was a simple telephone interview without technical depth (this might be explained by my resumé being thrown to the top of the pile by a current employee that I had met at a conference). I now know to walk away from jobs that don't ask programming questions, software design questions, or otherwise challenge my technical expertise during the interview. They probably aren't going to challenge my technical expertise between the hours of 9am and 5pm, either. Alas, I was fresh out of about 20 years of schooling, and didn't know any better then. I guess it's true that Education Never Stops.
I used to be a red hat satellite administrator. There were quite a few bugs in the system that prevented me from doing the things with the network that I would have liked (centralized configuration file management, custom package deployment issues). It took Red Hat about a year and a half to solve each of the bugs, from the time I submitted them to the bug tracker to the time that a patch came out. I'm somewhat competent with Java, and do believe that I could have fixed the problems myself. I was beginning to get a bit frustrated with Red Hat due to the little bugs that cropped up in the server, and the slowness to respond. I understand that software development and testing cycles are tough, but I kind of felt like, for the money (about $15k per year), a quicker fix was in order.
I also recognize that it's a tough decision for them to open source this thing which raises a lot of money for them. No doubt this will spawn some real service competition for Red Hat, as other companies will able to easily implement their own RedHat-derived operating system complete with a centralized management system. It does fix my "using open source software to sell a closed source service" gripe. It's definitely a brave move, so kudos to them.
I thought my original message was perhaps too harsh and didn't offer any ideas on solution. So I decided to write a reply to myself.
I'd like to emphasize that there are some great people that work in DARPA and the various other research labs. I was definitely fortunate to work with or at least meet with the people that I did during my time in DoD. Quite a few people are technical and smart, and can see some big problems that we're facing. That is an incredibly good thing. I think that, from a human resources angle, the research labs are facing a legitimate problem though: they need people with technical expertise and passion to do a job that does not utilize that technical expertise and passion in a very glamorous way. It is downright demeaning to a lot of people with advanced degrees in a subject to do a job that doesn't involve actually doing the stuff that they studied, but instead watching other people do that stuff (and often doing it wrong!).
It is incredibly hard for DARPA and other agencies to spin the job in the right way to smart people. My point is that they're going about this whole 'selling the job' thing wrong -- they should try to change the job a bit to make it more technical in order to get people interested. Maybe they (the Congress) could require government contractors to accept the government-employed contract manager into their fold as a department head, paid for by the government. It could certainly be an interesting experiment that might yield a good outcome (which, I daresay, would be research worth funding).
I spent two years of my life post-graduate school working at DoD research laboratories, and can say with some experience why Geeks should not join DARPA (or any government research lab). It can be summed up in one word: "research."
Government labs no longer do the stuff for the most part. There are still some pockets left, but they are few and far between, and shrinking. I graduated with a MS in computer science, with a two-year focus on computer security. I was offered a job in a research team with with a DoD lab and eagerly took it. But it wasn't research. It was contract management. Essentially, I got to read research proposals from companies, and decide whether or not those companies would be funded for their ideas. My ability to influence the actual research of the companies was quite limited. I was able to come up with 'calls for proposals,' that is, statements of new topics that we'd like proposals on from companies. By the time these ideas were raped^Wvetted by the various program and contract managers, the descriptions were so incredibly vague that the proposals received in response to the call were completely off-topic. I got frustrated very early on and left.
In my exit interview, I asked my supervisor to define research. His definition was adequate. I then asked him if that's what we did. He stammered a bit, and ultimately conceded that we, "facilitated research." We had a very interesting discussion. Due to research project overruns throughout the 80s, particularly with software projects, as well as the end of the Cold War, the Congress changed the focus of DoD research programs. New funding rules dictate that research projects are placed under contract. In this way, if a company is paid to do research and development on a project, and it fails to deliver, the government has some recourse. If actual government employees received funding and failed, there would not be much that congress could do to them (Congress could slash the non-salary portions of the failed project's budget, but that's not very intimidating to the employees when you think about it).
The place where the 'cool' stuff happens these days is by the contractors. If you want to work on ARPA and DARPA quality work, start a small business and start winning on SBIR awards. I wouldn't recommend actually working for DARPA or a government research lab, though, unless you really want to be a contract manager and not be very hands-on with technology and ideas.
This is pretty much the opposite of a grassroots movement.
Grassroots: people spontaneously talk about you, support you. Their actions are unpredictable, because, well, they are people and are not guided by a central authority.
Monolithic: top-down approach where policritter issues organizational guidelines and tells people what to do.
Looks like McCain is using the monolithic model here. Oops.
In the past, solar physicists observed that the sun once went 50 years without producing sunspots, coinciding with a little ice age on Earth that lasted from 1650 to 1700."
This is really really *really* hard to say. Our data on sunspots in prior to about 1750 is pretty dismal. Most of the mentions of sunspots are casual or even accidental observation. You can find a lot of data on this at the NOAA ftp site:
Note two things: One, that there were reports of sunspots between 1650 and 1700; two, that the data prior to 1749 is inaccurate and (pardon the pun) spotty.
Note that the monthly averages file (the second one) is fairly accurate, as the older data in that file was made by the Royal Observatory and the later data in that file was made by the NOAA. I find it really hard to jump to the conclusion that the little ice age was a result of sunspots. Without a time machine, I don't think we could say that with any degree of certainty.
The cost of distributing the virus is microscopic. If even a few people pay the ransom, the virus writer makes a very good return on their investment. In the end, it is probably worthwhile in the same way that spam is worthwhile (it makes a fair amount of money).
As with spam, the originator is unknown and unable to build a reputation. In the case of spam, the spammer will be blocked by mail servers if they use a common identity, so they end up purporting to be fictitious people. This doesn't seem to present a problem for the spammer, though, because there are enough gullible people "out there."
I think that there are two pretty major flaws with this idea:
1) Bandwidth. 802.11b uses 22Mhz of bandwidth for each of its channels. There is not 22Mhz of unallocated bandwidth at 25Mhz. I'm sure that compression techniques are better now than when 802.11 stuff was defined. However, looking at the FCC allocation chart, there isn't much unassigned bandwidth near 25Mhz. A few Mhz here and there, unless they're considering usurping ham radio and maritime bands and otherwise kicking people off of frequencies. I'm not sure what they're considering "unused". Someone with more knowledge of on data compression via radio techniques might chime in:).
2) Propagation. 25Mhz is right around 12 Meters, which the hams and DX CB radio folks will know can propagate hundreds and even thousands of miles, depending upon ionospheric conditions. Take the bandwidth problem above, and multiply it by the fact that the precious little slice of bandwidth you get might be stomped on by everyone in the US during peak sunspot activity. This is likely the reason that mobile carriers aren't interested in these frequencies.
I'm pretty sure this is a loser idea. If someone knows more than me, I'd love to learn more about this stuff, though.
Note to self: no hitting tabs and space bars while typing in a web browser:).
Anyway, the trust metric I was stating is, "I trust that I'm going to run on particular hardware, even though that hardware is in the physical possession of someone that is not trustworthy."
There will always be a financial incentive to break DRM. In fact, the harder you (the industry) make it to break DRM, the more it pays the people that *can* break it, because the competition is now that much smaller. Hacker kids will simply get a very nice oscilloscope to break your DRM scheme if it comes down to it. A few grand of equipment in order to break the scheme is nothing compared to the payoff achieved if you're the only one that can sell pirated versions of a program.
There is a glaring hole in the "TPM fixes everything" thing, as with every other piracy "solution". This time, it's called DMA.
A game or other program could license itself to a particular piece of hardware, given that that particular piece of hardware (the motherboard) has a cryptochip. How does a program then verify that it is only running on that particular hardware? It sounds like, from the article, the ploy is to encrypt part of the game program (or all of it) with the onboard TPM's public key, so that only the motherboard with that particular key can decrypt the game. Part of the registration or installation process would be to contact the vendor and obtain the part of the program in question, encrypted for your particular TPM.
That's great, but (and I love the word 'but' when referring to someone's Genius Plan to Implement DRM)...the game has to live in RAM unencrypted, or it would be too slow to play. In this case, I can make a specialized PCI/PCIe card whose sole purpose is to dump RAM. It will just DMA read all available memory and put it on its own 4GB compactflash card or some such. As soon as the unencrypted game hits my RAM, I'll have it to do with as I please. If the motherboard implements an IOMMU? I'll just hit my RAM with compressed air and freeze it, then read the bits out and hack as I please.
DRM won't work because its trust metric is screwed up. It basically says, "I trust that I'm going to run on particular hardware
Maybe the reason that the nameserver is providing correct responses is due to something like port-knocking for domain names?
If a phisher wanted to use this, they would only supply a bogus dns pointer to a query if the query was preceded by some 'primer' query. E.g. first someone tries to resolve alpha.com, then beta.com within a few seconds, only then will the root server give the incorrect response for beta.com. This would be pretty easy to do with some cross-site scripting magic.
There was success at my university. Dr. Jabbour at Syracuse I believe was able to determine previous data using an tunneling electron microscope and statistical inference (random data versus patterned will still leave a patterned magnetic imprint or some such, which I don't claim to know anything about). Of course, I can't find any reference to his stuff on the Goog...maybe it got yanked;-).
I think this worldwide fellowship thing can be promoted in a way that doesn't require athletic red carpets, and doesn't implicitly piss somebody off.
Amen to that. It used to be that olympic athletes held "amateur status," -- they weren't allowed to accept any form of payment for their sport. Jim Thorpe had his medals stripped because he got paid to play baseball in the *minor leagues*, which barely paid to put food on his table.
Overcompetition killed the olympics. The Olympics used to basically be, "Bob the Carpenter happens to be good at shot-put, so let him represent our country as an average citizen." I'd honestly watch them if it were amateur athletes competing again -- it's fun to think that, with enough working out in my spare time, I too could be an olympic cyclist. Now it's just mega-million athletes wearing logos from a shoe manufacturer that uses slave labor to make the money...not exactly something to be proud of.
For another (older but still very relevant) look at this and related issues (such as what to do with the plutonium by-product of power generating reactors), look no further than John McPhee's The Curve of Binding Energy. It's an extraordinarily interesting issue that will only become more pressing as time goes on. Unfortunately, it isn't as widely reported on as it used to be, which I suspect is due to political/embarrassment reasons...
This isn't news..GOV helped Sun build Trusted Solaris back in the day (they also helped Hewlett-Packard develop Trusted HP/UX). The government isn't doing this stuff to be evil, and I know my saying, "Don't be paranoid," won't make anyone any less paranoid -- but really the government needs certain security features to solve its problems (such as Cross-Domain information sharing), and the commercial industry simply doesn't need that stuff. Or, at least, it doesn't think it needs it. The only way for the government to get the OS features it needs is to work with a company directly to do it, or use an open source alternative.
Originally,.GOV decided to work with companies. Like I said, Trusted Solaris, Trusted HP/UX, and some others that I can't think of, were created. Along came Stephen Smalley and his FLASK security architecture. Linux was the first and easiest place to implement it, and the NSA spearheaded the project. You can imagine that Sun (the only vendor of an OS that supported multi-level data just a few years ago) wasn't all that happy --.GOV pretty much promised Sun, "If you build and maintain your trusted OS, we'll keep buying licenses and hardware."
Now that isn't so. It seems only fair to help Sun and the Solaris community in the same way that the government has helped RedHat and the Linux community: provide some resources and some know-how to make the OS do what the government wants, so as to not hand RedHat a huge government-assist...the government basically wants competition here. As a taxpayer, I can't say that I'm complaining...
I started as a unix developer and switched recently to programming in windows, and use.NET quite a bit (it was the job that was available at the time;-))..NET and Java are both prime examples of object-oriented programming gone stupid. Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them.
Give me fopen() any day.
There are a lot of things that I don't like about.NET (and particularly visual studio:)), but I think these arguments are invalid. fopen() is fine and good, but opening a file is a lot more complicated than just one posix function -- you have race conditions, concurrency issues, etc, if you're working on anything bigger than an academic project. You can develop your own libraries for safely doing things if you want, but going from job to job that becomes difficult legally (who owns the library?). And, of course, using some extra library to wrap your posix is kind of an argument against posix being the be-all-end-all uncomplicated solution.
Programmers often have areas of specialization, and not knowing more than a small portion of a gigantic library isn't necessarily a bad thing. I know the '.NET methodology' (and it is quite consistent) well enough that I could use other parts of the library. Quite frankly for my line of work I don't anticipate ever having to, as it's fairly niche.
Slashdot Mirror
I think, though, it's poor form for commercial entities to go ahead designing and releasing GPL based software without thinking ahead and accepting that they have to supply source code to their paying customers.
This is precisely the GPL tradeoff.
A lot of times a company can save itself some time and money by using an already-implemented GPL'd program. If a company goes this route, it pretty much has to define its product in one of two ways: hardware, and/or service.
Hardware company examples include Linksys (WRT54 routers), D-Link (Network Attached Storage devices), Sharp (Zaurus PDAs). I would be hard-pressed to call any of these companies 'hardware and service,' as they all pretty much release the hardware and then don't bother offering patched firmware (at least, none of them do it very often). They only make money off of the initial hardware sale, so they have little motivation to fix bugs -- especially when the community can do it for them.
Service companies include RedHat, Canonical, etc. Their bread and butter is selling you technical support and patch services, preferably every year. They do have a lot of motivation to give back to the community, precisely because if no-one else fixes a bug, their customers will walk away. Until recently, RedHat was probably one of those quasi-GPL-violators in my mind: the Red Hat Network was probably built using GPL'd building blocks, but the code was never released (until last week, woohoo!). Note my use of the word 'probably,' here -- I haven't gotten a chance to peruse the satellite server source code yet, I'm mostly speculating :).
Anyway, a company *can* make and save a lot of money by going with the GPL, so long as they fit one of those scenarios (or some other that I'm not thinking of). If a company wants to be a software license company, though, then the GPL is definitely not a wise choice ;-).
Reid
Just tried the GPL quiz. I did poorly I must say.
I'm still a bit confused about it, but it seems like they have to provide the sourcecode for the entire thing, except for stand-alone proprietary programs running 'separately' from everything else, and provided they aren't using GPL libraries.
A lot of people do poorly. I take it once ever year or so. I just took it, and I got one wrong. I don't think I've ever answered it 100% rightly. Maybe next year ;-).
It's funny to me, because I got modded troll on slashdot back in 2000 or so. I claimed that the NSA misunderstood an aspect of the GPL when they hired a contractor to work on SELinux (the contractor included patent-encumbered code in their implementation). People claimed that the GPL is so easy to understand and that I was an idiot, and also that the NSA could not have possibly misconstrued the legal ramifications of the GPL.
If only I could meet the legal geniuses that flamed me ;-).
I'm glad to see that people are actually asking questions about the GPL on slashdot these days, instead of just assuming that they know how it works. It brings a tear to my eye.
Is the end-user - at a public terminal - entitled to the same rights under GPL as the owner of the computer on which the software runs?
Here's a very weird answer. No. This is a point of contention for a lot of people, myself included...
In the case of a public terminal, the 'user' (and by user I mean non-owner) technically never agreed to the the terms of the license. They don't 'own' the binary version of the program, they are just along for the ride. The GPL only stipulates that owners of a binary copy of the program get access to the code. Once they have code, though, they are free to give it away to their friends...
The bigger point of contention for people lately has been web services. If facebook uses a GPL'd web server (or even some GPL'd web service implementation like phpBB) and makes modifications to it, but never releases the binaries to anyone, it can still use that modified server to provide services to people. You only get to use the http interface to the server, not technically the server itself, and so you have no right to the code. Of course, if facebook doesn't do a good job with NDAs, any one of its employees could release the modified code to the world. Facebook may fire the employee, but couldn't sue them. Technically the employee didn't do anything wrong in this example (unless, like I said, Facebook made the employee sign an NDA or some other legal document beforehand that stated the employee would not share modified source code...then Facebook could sue their pants off for violating that agreement).
This whole shebang was, iirc, brought up in the early drafts of the GPLv3. It is hard to say what the right answer here is. I kinda lean towards the 'openness' side of the issue. I submitted a patch to the web server, and if a company modifies the webserver to suit their needs, I would love for them to be required to share their change with the world. The GPL is all about this flow of ideas. Companies, naturally, need to make a profit. If they tweak some software to provide a unique service, they want to protect their investment by not giving the investment away to competitors for free. I guess we'll see who wins in GPLv4 :).
Reid
Sounds like you need to take the GPL quiz. This particular issue is addressed in Question 1 of said quiz.
Don't worry, you're definitely not alone in any misunderstandings of the GPL...lots of people think they understand all the legal aspects of it completely when they don't. I used to be guilty myself. Now I just don't claim to know everything about the GPL ;-).
In "Surely You're Joking, Mr. Feynman," Richard wrote an anecodte about just this: he went to bars and tried to meet women, but they wouldn't sleep with him. Finally, he went to a bar one night and treated a woman like garbage: made her pay for the drinks, barely paid attention to her, etc. He scored. And it worked again and again and again...
Question: What would the penalty be if this was not a computer crime? Suppose he broke into the school's office and changed the grades records for several students?
One count of breaking and entering, and 34 counts of altering a public record? Would these even be federal crimes?
My mother teaches in a high school, and was talking about their new online grading system. She has to submit grades via the web service, and students are able to log in to the same web interface to read their grades. I asked my mother if the school kept other documentation of student grades (for example, if she had to turn in a grade book at the end of the year so that the university could compare the online version to her paper version). The answer was no. The high school relies completely on the online system for determining grades. This is accessible via the internet. The software is called Genesis Passport. Not a lot of information is available about it online, but I have to wonder if the thing could possibly be secure. I kind of doubt it, but what do I know, I'm only a professional security researcher and pen-tester...
I'd be quite happy if this is how DARPA advertises. I can't speak to whether or not it is, as I never worked for them. I can say that I now recall during my pitching ideas to a DARPA PM, he was essentially offering me a job, saying that if I ever wanted a challenging research director-type position, I should consider sending him my resumé. It was quite obvious from his pitch that it would be more manager-oriented. Perhaps some day I shall send my resumé in, when I am ready to relax my typing hands a bit ;-).
I do know that the Air Force Research Laboratory (one of my previous employers), advertised to candidates that they did 95% of their research in-house. I actually asked to have read access to the AFRL time-tracker database before I left. Somewhere less than 10% of the time billed that year was spent on what is known as 6.1 ("Basic Research") funded projects. I know first-hand that this number was fudged a bit -- there were certainly projects calling themselves basic research that indeed were not. The rest of the time was charged to what are called 6.2 and 6.3 efforts, which are projects already under contract with a company (so program management, contract management). I did feel like I was lied to by the recruiters at AFRL, particularly that they asserted during their presentations that they were almost exclusively in-house research. They seemed to present an awful lot of projects as having been developed internally, when in fact they were researched and implemented by contractors.
I worked in the Space and Naval Warfare Systems Center, and they were about 10 million times better. Many department heads in that organization encouraged my efforts to do Real Research, and spent a lot of time helping me out. Mind you, they don't have Research Lab in their title. The folks at SPAWAR are awesome in this way. Ultimately, love and a lot more money took me into the private sector, where I happily work on some big problems and feel a lot more productive. I do regret leaving the fine folks in the Navy behind, as I think that work there would have evolved to be very much to my liking.
One big thing I learned from my time at both of these government positions was that interviews are extraordinarily important. My interview process lasted about 4 hours at AFRL, and did not involve any in-depth technical session. My interview process with SPAWAR was a simple telephone interview without technical depth (this might be explained by my resumé being thrown to the top of the pile by a current employee that I had met at a conference). I now know to walk away from jobs that don't ask programming questions, software design questions, or otherwise challenge my technical expertise during the interview. They probably aren't going to challenge my technical expertise between the hours of 9am and 5pm, either. Alas, I was fresh out of about 20 years of schooling, and didn't know any better then. I guess it's true that Education Never Stops.
Reid
I used to be a red hat satellite administrator. There were quite a few bugs in the system that prevented me from doing the things with the network that I would have liked (centralized configuration file management, custom package deployment issues). It took Red Hat about a year and a half to solve each of the bugs, from the time I submitted them to the bug tracker to the time that a patch came out. I'm somewhat competent with Java, and do believe that I could have fixed the problems myself. I was beginning to get a bit frustrated with Red Hat due to the little bugs that cropped up in the server, and the slowness to respond. I understand that software development and testing cycles are tough, but I kind of felt like, for the money (about $15k per year), a quicker fix was in order.
I also recognize that it's a tough decision for them to open source this thing which raises a lot of money for them. No doubt this will spawn some real service competition for Red Hat, as other companies will able to easily implement their own RedHat-derived operating system complete with a centralized management system. It does fix my "using open source software to sell a closed source service" gripe. It's definitely a brave move, so kudos to them.
I thought my original message was perhaps too harsh and didn't offer any ideas on solution. So I decided to write a reply to myself.
I'd like to emphasize that there are some great people that work in DARPA and the various other research labs. I was definitely fortunate to work with or at least meet with the people that I did during my time in DoD. Quite a few people are technical and smart, and can see some big problems that we're facing. That is an incredibly good thing. I think that, from a human resources angle, the research labs are facing a legitimate problem though: they need people with technical expertise and passion to do a job that does not utilize that technical expertise and passion in a very glamorous way. It is downright demeaning to a lot of people with advanced degrees in a subject to do a job that doesn't involve actually doing the stuff that they studied, but instead watching other people do that stuff (and often doing it wrong!).
It is incredibly hard for DARPA and other agencies to spin the job in the right way to smart people. My point is that they're going about this whole 'selling the job' thing wrong -- they should try to change the job a bit to make it more technical in order to get people interested. Maybe they (the Congress) could require government contractors to accept the government-employed contract manager into their fold as a department head, paid for by the government. It could certainly be an interesting experiment that might yield a good outcome (which, I daresay, would be research worth funding).
I spent two years of my life post-graduate school working at DoD research laboratories, and can say with some experience why Geeks should not join DARPA (or any government research lab). It can be summed up in one word: "research."
Government labs no longer do the stuff for the most part. There are still some pockets left, but they are few and far between, and shrinking. I graduated with a MS in computer science, with a two-year focus on computer security. I was offered a job in a research team with with a DoD lab and eagerly took it. But it wasn't research. It was contract management. Essentially, I got to read research proposals from companies, and decide whether or not those companies would be funded for their ideas. My ability to influence the actual research of the companies was quite limited. I was able to come up with 'calls for proposals,' that is, statements of new topics that we'd like proposals on from companies. By the time these ideas were raped^Wvetted by the various program and contract managers, the descriptions were so incredibly vague that the proposals received in response to the call were completely off-topic. I got frustrated very early on and left.
In my exit interview, I asked my supervisor to define research. His definition was adequate. I then asked him if that's what we did. He stammered a bit, and ultimately conceded that we, "facilitated research." We had a very interesting discussion. Due to research project overruns throughout the 80s, particularly with software projects, as well as the end of the Cold War, the Congress changed the focus of DoD research programs. New funding rules dictate that research projects are placed under contract. In this way, if a company is paid to do research and development on a project, and it fails to deliver, the government has some recourse. If actual government employees received funding and failed, there would not be much that congress could do to them (Congress could slash the non-salary portions of the failed project's budget, but that's not very intimidating to the employees when you think about it).
The place where the 'cool' stuff happens these days is by the contractors. If you want to work on ARPA and DARPA quality work, start a small business and start winning on SBIR awards. I wouldn't recommend actually working for DARPA or a government research lab, though, unless you really want to be a contract manager and not be very hands-on with technology and ideas.
This is pretty much the opposite of a grassroots movement.
Grassroots: people spontaneously talk about you, support you. Their actions are unpredictable, because, well, they are people and are not guided by a central authority.
Monolithic: top-down approach where policritter issues organizational guidelines and tells people what to do.
Looks like McCain is using the monolithic model here. Oops.
In the past, solar physicists observed that the sun once went 50 years without producing sunspots, coinciding with a little ice age on Earth that lasted from 1650 to 1700."
This is really really *really* hard to say. Our data on sunspots in prior to about 1750 is pretty dismal. Most of the mentions of sunspots are casual or even accidental observation. You can find a lot of data on this at the NOAA ftp site:
Reports of sunspots from 164BC to 1918AD
Monthly average of sunsports from 1749 to present
Note two things: One, that there were reports of sunspots between 1650 and 1700; two, that the data prior to 1749 is inaccurate and (pardon the pun) spotty.
Note that the monthly averages file (the second one) is fairly accurate, as the older data in that file was made by the Royal Observatory and the later data in that file was made by the NOAA. I find it really hard to jump to the conclusion that the little ice age was a result of sunspots. Without a time machine, I don't think we could say that with any degree of certainty.
The model kind of reminds of spam.
The cost of distributing the virus is microscopic. If even a few people pay the ransom, the virus writer makes a very good return on their investment. In the end, it is probably worthwhile in the same way that spam is worthwhile (it makes a fair amount of money).
As with spam, the originator is unknown and unable to build a reputation. In the case of spam, the spammer will be blocked by mail servers if they use a common identity, so they end up purporting to be fictitious people. This doesn't seem to present a problem for the spammer, though, because there are enough gullible people "out there."
I think that there are two pretty major flaws with this idea:
:).
1) Bandwidth. 802.11b uses 22Mhz of bandwidth for each of its channels. There is not 22Mhz of unallocated bandwidth at 25Mhz. I'm sure that compression techniques are better now than when 802.11 stuff was defined. However, looking at the FCC allocation chart, there isn't much unassigned bandwidth near 25Mhz. A few Mhz here and there, unless they're considering usurping ham radio and maritime bands and otherwise kicking people off of frequencies. I'm not sure what they're considering "unused". Someone with more knowledge of on data compression via radio techniques might chime in
2) Propagation. 25Mhz is right around 12 Meters, which the hams and DX CB radio folks will know can propagate hundreds and even thousands of miles, depending upon ionospheric conditions. Take the bandwidth problem above, and multiply it by the fact that the precious little slice of bandwidth you get might be stomped on by everyone in the US during peak sunspot activity. This is likely the reason that mobile carriers aren't interested in these frequencies.
I'm pretty sure this is a loser idea. If someone knows more than me, I'd love to learn more about this stuff, though.
Reid
Note to self: no hitting tabs and space bars while typing in a web browser :).
:).
Anyway, the trust metric I was stating is, "I trust that I'm going to run on particular hardware, even though that hardware is in the physical possession of someone that is not trustworthy."
There will always be a financial incentive to break DRM. In fact, the harder you (the industry) make it to break DRM, the more it pays the people that *can* break it, because the competition is now that much smaller. Hacker kids will simply get a very nice oscilloscope to break your DRM scheme if it comes down to it. A few grand of equipment in order to break the scheme is nothing compared to the payoff achieved if you're the only one that can sell pirated versions of a program.
That is all
There is a glaring hole in the "TPM fixes everything" thing, as with every other piracy "solution". This time, it's called DMA.
A game or other program could license itself to a particular piece of hardware, given that that particular piece of hardware (the motherboard) has a cryptochip. How does a program then verify that it is only running on that particular hardware? It sounds like, from the article, the ploy is to encrypt part of the game program (or all of it) with the onboard TPM's public key, so that only the motherboard with that particular key can decrypt the game. Part of the registration or installation process would be to contact the vendor and obtain the part of the program in question, encrypted for your particular TPM.
That's great, but (and I love the word 'but' when referring to someone's Genius Plan to Implement DRM)...the game has to live in RAM unencrypted, or it would be too slow to play. In this case, I can make a specialized PCI/PCIe card whose sole purpose is to dump RAM. It will just DMA read all available memory and put it on its own 4GB compactflash card or some such. As soon as the unencrypted game hits my RAM, I'll have it to do with as I please. If the motherboard implements an IOMMU? I'll just hit my RAM with compressed air and freeze it, then read the bits out and hack as I please.
DRM won't work because its trust metric is screwed up. It basically says, "I trust that I'm going to run on particular hardware
Maybe the reason that the nameserver is providing correct responses is due to something like port-knocking for domain names?
If a phisher wanted to use this, they would only supply a bogus dns pointer to a query if the query was preceded by some 'primer' query. E.g. first someone tries to resolve alpha.com, then beta.com within a few seconds, only then will the root server give the incorrect response for beta.com. This would be pretty easy to do with some cross-site scripting magic.
You can never disprove a conspiracy, after all...
The jet engine on the car thing was debunked, though I think someone should try to make it a reality... ;-)
There was success at my university. Dr. Jabbour at Syracuse I believe was able to determine previous data using an tunneling electron microscope and statistical inference (random data versus patterned will still leave a patterned magnetic imprint or some such, which I don't claim to know anything about). Of course, I can't find any reference to his stuff on the Goog...maybe it got yanked ;-).
I think this worldwide fellowship thing can be promoted in a way that doesn't require athletic red carpets, and doesn't implicitly piss somebody off.
Amen to that. It used to be that olympic athletes held "amateur status," -- they weren't allowed to accept any form of payment for their sport. Jim Thorpe had his medals stripped because he got paid to play baseball in the *minor leagues*, which barely paid to put food on his table.
Overcompetition killed the olympics. The Olympics used to basically be, "Bob the Carpenter happens to be good at shot-put, so let him represent our country as an average citizen." I'd honestly watch them if it were amateur athletes competing again -- it's fun to think that, with enough working out in my spare time, I too could be an olympic cyclist. Now it's just mega-million athletes wearing logos from a shoe manufacturer that uses slave labor to make the money...not exactly something to be proud of.
For another (older but still very relevant) look at this and related issues (such as what to do with the plutonium by-product of power generating reactors), look no further than John McPhee's The Curve of Binding Energy. It's an extraordinarily interesting issue that will only become more pressing as time goes on. Unfortunately, it isn't as widely reported on as it used to be, which I suspect is due to political/embarrassment reasons...
This isn't news. .GOV helped Sun build Trusted Solaris back in the day (they also helped Hewlett-Packard develop Trusted HP/UX). The government isn't doing this stuff to be evil, and I know my saying, "Don't be paranoid," won't make anyone any less paranoid -- but really the government needs certain security features to solve its problems (such as Cross-Domain information sharing), and the commercial industry simply doesn't need that stuff. Or, at least, it doesn't think it needs it. The only way for the government to get the OS features it needs is to work with a company directly to do it, or use an open source alternative.
.GOV decided to work with companies. Like I said, Trusted Solaris, Trusted HP/UX, and some others that I can't think of, were created. Along came Stephen Smalley and his FLASK security architecture. Linux was the first and easiest place to implement it, and the NSA spearheaded the project. You can imagine that Sun (the only vendor of an OS that supported multi-level data just a few years ago) wasn't all that happy -- .GOV pretty much promised Sun, "If you build and maintain your trusted OS, we'll keep buying licenses and hardware."
Originally,
Now that isn't so. It seems only fair to help Sun and the Solaris community in the same way that the government has helped RedHat and the Linux community: provide some resources and some know-how to make the OS do what the government wants, so as to not hand RedHat a huge government-assist...the government basically wants competition here. As a taxpayer, I can't say that I'm complaining...
Reid
I just checked out the fed's kiddieporncatcher website and they don't have a robots.txt on it. Hang on, there's someone at my door...
Hey guys, check this out!
Seriously, isn't this kind of hyperlinking kind of ripe for abuse? What happens if the googlebot accidentally follows the link and spiders the site?
Reid
I started as a unix developer and switched recently to programming in windows, and use .NET quite a bit (it was the job that was available at the time ;-)). .NET and Java are both prime examples of object-oriented programming gone stupid. Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them.
.NET (and particularly visual studio :)), but I think these arguments are invalid. fopen() is fine and good, but opening a file is a lot more complicated than just one posix function -- you have race conditions, concurrency issues, etc, if you're working on anything bigger than an academic project. You can develop your own libraries for safely doing things if you want, but going from job to job that becomes difficult legally (who owns the library?). And, of course, using some extra library to wrap your posix is kind of an argument against posix being the be-all-end-all uncomplicated solution.
Give me fopen() any day.
There are a lot of things that I don't like about
Programmers often have areas of specialization, and not knowing more than a small portion of a gigantic library isn't necessarily a bad thing. I know the '.NET methodology' (and it is quite consistent) well enough that I could use other parts of the library. Quite frankly for my line of work I don't anticipate ever having to, as it's fairly niche.
Reid