Take a look at Surrey Satellite Technology http://www.sstl.co.uk./ They have a selection of standard platforms and payloads (or BYO payload). Their standard platforms/payloads focus is EO and Comm/Nav, but not limited to those.
However, if you go to any of the majors, they'll also start with a standard bus; they just don't market that part heavily because the value/money is elsewhere. I doubt there are very many commercial sats/payloads built on a one-off/custom bus these days. Those that are most likely are relatively high volume (e.g., GPS, Iridium, etc.). (Hughes started doing that long ago for comm sats).
IIRC (sorry, it was long ago)... on the Pioneer 10//F 11/G missions Van Allen spec'd the Geiger Tube Telescope for an order-of-magnitude more than expected, and we pegged them. Pioneer suffered significantly--never regained full range on one channel of the IPP (Imaging Photopolarimeter--that thing that made the pretty pictures possible).
We nearly lost the spacecraft due to some spurious crap/commands during periapsis on Pioneer 10/F. Try dealing with an idiot-savant-brain-damaged-two-year-old throwing a tantrum with ~90-minute round-trip light time at 256-1024bps. It's ugly.
The running joke was... If you want to be absolutely certain a spacecraft is sterile, just make a flyby of Jupiter. Jupiter's belts are not to be taken lightly. A seriously understated quote from one post-mission presentation "Closest approach: It’s hot in there!"
It's not just hot, it's a red-hot-poker enema in your electronic guts. That Pioneer 10/11 F/G--the epitome of cheap deep-space exploration--survived those encounters and lived to tell--and did so for many more years still amazes me.
It is a testament to what we can do, and what deep-space exploration is all about. (So allow me a bit of hubris: Suck eggs Voyager... you had a much bigger budget, you got the press, you got your name in a Star Trek movie, but we were there first. Nah nah nah.)
Hogwash. The US may has been dicking around, but others haven't. Your comment typifies everything wrong with the typical US attitude to space exploration.
The Russians were in space almost continuously from 1971 onwards--from Salyut, through to Mir and then the ISS--running manned missions and supply flights almost continuously until the present. The only pause in the Russian program was a couple years between the time Mir came down and the first ISS module was put up (again, the Russians).
From 1971-present the US couldn't put a man in space for years over several periods: after Skylab; after Challenger; after Columbia. Meanwhile, the Russians continued to grind along, slowly but surely, providing both manned and unmanned supply flights. Those Progress and Soyuz flights that helped keep the ISS alive? Those were from Russia, using proficiences they developed during the 20+ years *regularly* servicing Salyut and Mir and maintaining a manned presence in space.
Check the total time in orbit for the Salyut and Mir, days inhabited, and the number of missions--it's pretty damned impressive. And that was long before the ISS or the Shuttle.
They weren't "dicking around". They were doing serious science on long-term manned missions, and what it takes to sustain an effort, especially from an operational/practical perspective. It's no accident that a lot of the practical ISS LS systems are based on what the Russians learned and developed. NASA has refined some of those systems, but a lot of the basic tech (air revitalization, toilets, etc.) came from the Russian program.
This isn't a "race", at least if you're interested in more than flags and boots. It's learning. It's exploration not just of places, but of systems. It's engineering. It's figuring out how to make people and machinery work in environments that are hostile and for which many effects are little understood. You do that by trying, correcting, and trying again. That takes time and a sustained effort.
Good for them. Nothing really new here, but someone has to make it clear that we aren't going anywhere much beyond the atmosphere on a sustained basis without nuclear power in space.
That includes space guns, space elevators, and whatnot--you need a tugs ("orbital transfer vehicles") to collect all those cheap/dumb parcels and deliver them to where they're needed. Or you use larger/smarter and more expensive vehicles with automonous maneuvering systems (which is what we do today), and which is why (*cough*) $5-10K/Kg-to-LEO turn into $20-80K/Kg of net payload (usable payload minus delivery vehicle structure, guidance, propellant, etc.
Advanced propulsion (e.g., hall-effect/ion/vasimir/thermal) with solar electric power might be OK for slow orbital or cislunar tugs, but are limited due to mass penalties and array degradation. Such systems need power to get anywhere in a reasonable amount of time, and the more power (in general) the better. Fusion? Maybe someday.
If we in the West can't manage to swallow our aversion to nuclear power in space (real power, not RTG's), then we will cede space to those who will, whether Russia, China, India or whoever. Maybe when they esablish a sustainable LEO and cislunar system (or a Mars effort) using nukes people will wake up (Sputnick redux), but I won't hold my breath.
Pick your poision... Very limited and occassional manned exploration using chemical propulsion, or a long term and sustainable effort using nuclear power/propulsion. I'd prefer the latter.
1. In round numbers: . ~9.5 km/sec to LEO (given, approximate) . ~6.0 km/sec from gas gun (FTA) . ~0.5 km/sec atmospheric drag (FTA) = ~4.0 km/sec needed from projectile rocket . 350s ISP for projectile rocket (assumed, optimistic) = 0.69 propellant fraction . 450Kg projectile (FTA) = 310Kg projectile rocket propellant = 140Kg projectile non-propellant . ???Kg projectile structure, motor, etc. = ???Kg net cargo to LEO (in any case, 140Kg)
2. Assuming you want to rondezvous with something in an established orbit (e.g., the ISS), any significant orbital maneuvering is out of the question; in paticular an orbital plane change--whether by the projectile or the target--as it's too expensive.
That limits the number of launch windows. You can't simply launch projectiles into orbit as fast as the gun can fire, otherwise you'll end up with them scattered in various orbits that you have to chase down (again, very expensive).
E.g., there are nominally 2 launch windows/day for Shuttle flights from KSC to the ISS. (Due to various rules, in practice it's limited to 1/day, but we'll ignore that.)
3. Even with optimal launch parameters, orbital rondezvous is still non-trivial, and one reason why even unmanned ISS resuplly vehicles are much more than simply a dumb ballistic container, and have, e.g., OMS and RCS motors, propellant and the weight/complexity/cost penalties that come with them.
Which is why larger, more infrequent and expensive missions will remain the norm for the foreseeable future--with or without a space gun or its ilk.
4. In short, we need an orbital infrastructure that can handle smaller/dumber vehicles. That doesn't exist, and few if any of these proposals account for it. With, e.g., a group of ion/electric tugs it may make more sense. That is, something that can cost-effectively collect those smaller/dumber vehicles and bring them to where they're needed.
The transporter has a service ceiling of 15,000 feet with Shuttle attached, that would given them an additional 6.4PSI of differential. With the other methods (and a bit more altitude if they can manage it, even for only a short period), it might be close enough.
Beg to differ. (Maybe I'm missing something by not spending more time on the crapper or in the tub reading. I just don't get the appeal.)
I have a huge library of conventional books (about 2K volumes). I have been getting rid of them in favor of ebooks whenever possible. My ebook library now runs to > 150 purchased. (Still mostly SF though because it's hard to find ebook replacements for a lot of my conventional titles, especially non-fiction; SF is about the only fiction I indulge in.)
When reading an ebook I am at my computer, and most of the time Internet connected. I can click on a word or phrase and google it. I am addicted to it. When I can't do that conveniently, I feel deprived and annoyed. Yes, I own dictionaries and encyclopedias, but the Web is often far more informative, convenient and fun. Especially for esoteric content.
I also find it much more convenient when traveling to carry reading material on my laptop, rather than having to lug pounds of paper around (an 18hr flight takes a *lot* of pounds of paper). Especially for "disposable" content. And I no longer feel guilty about dead trees. Then again, the inability to donate an ebook, as I normally do with conventional disposable content when I'm done with them, is one of the very few downsides of ebooks.
p.s. Stay away from "protected" ebooks. Pain in the a**. And if you're into SF, check out Baen, who has not only a large number of volumes for sale, but also a significant "free" library. (And you can get them in a very nice HTML format so you can read them on just about anything). See: http://www.baen.com http://www.baen.com/lib rary
Re:.net is great if your already an MS shop
on
Java vs .NET
·
· Score: 2, Interesting
It was originally intended to illustrate various Java technologies and the application of those technologies. It was intended to be a *teaching* tool.
To take such an illustrative example, rearchitect it, then make any claims about efficiency, is/was ludicrous. Like taking sample code out of a book on Java, and then showing how an expert.Net programmer can do it so much more efficiently.
Do some more research and you'll find that the Petshop project has been completely discredited as a comparison of Java and.Net.
That's a great example of where technology can have a really bad effect on a sport.
I loved fencing in a previous life. But I really hated electrics for the reasons you state... strategy went out the window and every engagement seemed to turn into a kamikaze blitz.
My only solace is that if it had been real swordplay, I might have come away with a few nicks, but my opponents would have looked they had been run through a Quisinart. (damn that was fun. and i'm one of those pr*cks who always used a *really* stiff blade.:)
Unfortunately, the weight of your bike lock...
on
Sports Technology?
·
· Score: 1
...is still inversely proportional to the weight of your bike. Alas, with all this progress, all bikes still weigh 50 pounds: - A 49-pound bike requires a 1-pound lock. - a 1-pound bike requires a 49-pound lock.
You're correct that trustable code would be a benefit. However, a trusted computer and software is only one component of a much larger and more complex process--that entire process must be secure.
An example is (or was) the Nevada Gaming Commission's requirements for electronic games. It's been a very long time since I had anything to do with that--I was involved when electronic games were first being considered--but the requirements being discussed then were draconian. Wxtremely strict auditing requirements for everything from software development through to operation of the system and physical safeguards. (We use to joke that getting a C2 certification was easier.:)
I looked through the document Ryano pointed at in a previous post. In short...
There are two different parts to the system: 1. The voting machine, or "IES" (Integrated Election System). Proprietary hardware and software (68000-based). 2. The Windows workstation that runs the "EMS" (Election Management System). That is used for "personalizing" the IES and tallying the data from the IES.
The doc is primarily concerned with the IES, which requires 120KB of EPROM; they state the size of the source is 1.1MB.
So it's doubtful the IES firmware is anywhere near 200,000 lines. The EMS, with a bunch of fancy UI and database stuff, may very well be 200,000 lines.
The web site and source code for the Australian system referred to in the article is worth a look.
It's quite simple. Intentionally, as the ACT states in their design goals (http://www.elections.act.gov.au/EVACS.html). The source includes the client and server application components--160 files and 12739 lines of very straigtforward C. (Of course, that doesn't include the OS/libs.)
I've browsed through a fair bit of the code, and everything I've seen is GPL. Ensuring accessibility to software used for public elections is, I think, a Very Good Thing. (I wouldn't mind seeing a law that required all election software be GPL'd.)
Re:Ok, how about "zillions of Linux users."
on
Linux Is Cheaper
·
· Score: 1
Cool -- thanks for the info.
It looks like what you suggest would be most successful in a situation where the users don't roam too far, and have a limited set of functions that need to be performed. I think that describes about 90% of the typical office environments. (I never thought of using CD's--have to think about that some more.) However...
Scaling into the thousands probably requires a very different animal. That has been done with UNIX and appliances (diskless workstations, NFS home/work directories, etc.) for years. However, there's a significant investment in network and infrastructure required--the network has to be extremely reliable and provide very good performance. That's not an insurmountable barrier, but I don't think many networks that are Windows-centric have the reliability/performance required. (I have no quantitative data, just anecdotal evidence.)
One of the most significant barriers is not the administrative side, although it is reflected in adminstrator's views: user's fear of losing "their" computer (for whatever reason--and there are many) is an extremely difficult barrier to overcome. Unfortunately we get into a vicious cycle, as a less reliable or lower performance network/infrastucture reinforces the desire by users--especially "power users", and those with the $ authority--to retain a desktop system that can operate autonomously. And most of those users also use laptops and roam between offices.
In short, making the leap from where organizations are today with a conventional PC-per-desktop, to a diskless/appliance desktop model seems to be too large for organizations to take in one step. That we'll eventually get there I have no doubt. It's the in-between step that seems to be a problem. Who knows, MS's pushing "smart displays" may do it. (And wouldn't that be ironic.)
p.s. I'm not, nor have I ever been, a Windows admin. I advise clients on solutions for enterprise IT problems. A fundamental problem is that clients often state problems or requirements with a pre-conceived notion of the solution space. ("You say you need a car that goes 600mph? Wouldn't an airplane be better? Oh, you've never heard of airplanes?") Your characterization of that as lack of imagination is correct, but that's more often than not what we're dealing with.
Ok, how about "zillions of Linux users."
on
Linux Is Cheaper
·
· Score: 1
Ok, since you seem to lack the imagination required to interpret "desktop" outside of a narrow and preconceived context, I'll try to be more specific...
"Zillions of end users using Linux as their primary application platform in an enterprise environment using X." Where you can fill in "X" with your choice.
The idea of network appliances, which is basically what you are suggesting, or their equivalent, is not new. I am intimately familiar with them. And the issues that have kept them from wide scale adoption. (And I suggest you climb off your high horse and study those failed deployments before throwing insults around.)
If that is your suggestion--and your experience, wonderful. We'd also like to know you got buyin. And how you manage the resulting deployments.
But please... If you have something useful to add, add it without insulting others.
For desktop, server or infrastructure?
on
Linux Is Cheaper
·
· Score: 1
The study is not specific enough to make a blanket "Linux vs. Windows" claim.
For application servers I think the study is correct, just based on my casual observations (e.g., managing a farm of Apache or Samba servers).
For desktops it's not clear. Active Directory and Group Policy Objects make managing 50K+ desktops feasible. I don't see anything on the Linux side that can cope with that magnitude of desktops.
I sure don't know how to answer the desktop management question when talking about zillions of Linux desktops.
Can someone who has experience with large scale Linux desktop deployments share their experience?
From what you've said, it sounds like your customer is footing the bill for the development. That is typically called "work for hire", and they who hires owns the work.
However, it is not unusual to find agreements where the funder [them] retains a "prepetual, world-wide, right to use license" for the product/IP (which does not include the right to resell, redistribute, create derivative works, etc.); the hiree [you] retains all other rights to the IP.
There are many, many, many boilerplate agreements of that sort floating around. A master service agreement from virtually any large development or consulting outfit will likely contain verbiage you could lift verbatim.
That said, talk to an attorney; they shouldn't charge you much for crafting this type of verbiage, since it's very common.
You can't change the past. But you can draw a line in a non-confrontational way, where you define your future relationship...
Dear,
Glad I could help out with . As I have demonstrated in the past, I enjoy the opportunity to solve problems and assist in any way possible.
In the event you require additional assistance, I have attached my standard price schedule. I'd be happy to discuss discounts for extended work, or on-call or after hours rates.
I look forward to working with you again in the future.
132 MB/sec xfer rate -- Nothing to get excited about; it's PCI bus bandwidth limited. I can saturate the PCI bus with RAID (IDE or SCSI) already. I can do better than 132MB/sec using a 64-bit or PCIX RAID controller, which this "drive" doesn't appear to offer.
100,000 I/Os per sec -- That is smokin', but how many I/Os are going to be single-sector reads? You'd be better off with more main memory buffer space to reduce small I/Os, which gets back to the question of xfer rate.
So you end up with a very high priced disk with none-to-exciting xfer rates but excellent seek times. Moreover, it takes up a PCI slot, which limits expandability.
It would make more sense if they make it look like a SCSI 160/320 drive (or array). It would have far greater expandability; still have bus-limited xfer rate; but a slightly higher access time.
It is true if you change the playing field, which is the point of the article.
RIAA+Labels = Promotion + Distribution + Obstructionism
Internet = RIAA+Labels - Distribution - Obstructionism
What's left is promotion. So how do other industries deal with promotion? They use "adverising" or "PR" firms. But those firms don't (and shouldn't) get a lock on the intellectual property associated with the product just for promoting it.
The functions of promotion and distribution will not disappear, but their implementation in the form of the RIAA and labels can, and should, be replaced.
The power to make the change is in the hands of artists. Artists could set up their own alternative to the RIAA and labels at any time. Why haven't they? The technology is a no-brainer.
No, this doesn't address physical CD distribution. But look at the context of this discussion, the debate, and the industry's cry for action against piracy--it all centers around the Internet. That's where the solution needs to start.
Obviously a replacement wouldn't address the back catalogs controlled by the labels. However, once a viable alternative is in place, the labels would probably be much more amenable to rational negotiation.
In short: 1. Construct a viable alternative; then 2. Bring the RIAA & Labels to the table; then 3. Negotiate acces to the back catalogs.
Anything else is wishful thinking--and whining--and requires the largesse of the RIAA and the labels (good luck).
Sometime in the last 60's or early 70's (?) there was research into the relative effiency of innovation and R&D in the U.S. and the Soviet Union. I believe the research was conducted in response to similar concerns about some research being sequestered in the U.S.
While there were many causes cited, one of the most significant conclusions of the paper was that the U.S. was far more efficient because of the openness of the U.S. R&D community. Specifically, that U.S. military research could benefit significantly by adopting a "no secrets" approach. (As you might imagine, that was quite controversial within the DoD community.) And, while the Soviet Union led in certain areas, cross-discipline pollination suffered, as did application.
All this should be intuitively obvious to anyone who's watched ideas spread and grow, which fosters a virtuous cycle, which is inhibited by secrecy. I'm sure other research has been done in this area by now, but this was the first time (at least that I know of) that it was taken beyond the "inutitively obvious" stage.
I can't find the paper on the web (my paper copy disappeared long ago), and I don't remember who conducted or sponsored the research, but the findings caused quite a stir and debate which is why I remember it. If anyone out there has a solid reference, I'd very much appreciate it. Thanks.
Every dev group should have a librarian
on
Libraries Are 31337
·
· Score: 5, Interesting
One of the first things I did when I took on the responsibility of managing a dev team was to hire a librarian. (A real, trained librarian, not a "code librarian".)
It was the best investment I ever made. It didn't take long before virtually everyone's first stop with a question was the library/librarian. Reference material, competitive info, standards, you name it... the librarian knew how to take piles of information in whatever form and organize it, make it accessible, and make it far more usable to everyone.
If you have a dev group of more than 15-20, your dev group is wasting time and money by not having a professional librarian on the team. It's a job that's part administrivia, part science, and part art. I have yet to find any other discipline that blends those parts as effectively as library science.
(I have to admit I've always had a soft spot for librarians, probably because I spent so much time in libraries. I have also been extremely impressed by librarians understanding of applying technology for information management, and the very progressive ideas that came out of library sciences. That doesn't always translate to high tech libraries or systems, but that's more often than not a funding issue.)
Re:A question for an artist familiar with the RIAA
on
Dealing with the RIAA?
·
· Score: 1
I understand plantation mentality. But I don't buy it--at least not completely. So I'll ask the question differently:
Why should I, or anyone, shed any tears over the artist's "suffering", and complain about the label's or RIAA's mistreatment of the artists...
Why should I, or anyone, shed any tears over the the label's or RIAA's intrasigence when it comes to innovative distribution models......when without the buy-in of the artists, any alternative is doomed to fail?
Mind you, I'm not convinced one way or the other, which is why the question was posed to an artist who is familiar with the RIAA.
I'd really like to know what the impediment is. Is it really a plantation mentality as you suggest? That artists don't have a sufficient grasp of the technology to understand the alternatives? That the labels/RIAA have some other power that prevents such an alternative?
Slashdot Mirror
Take a look at Surrey Satellite Technology http://www.sstl.co.uk./ They have a selection of standard platforms and payloads (or BYO payload). Their standard platforms/payloads focus is EO and Comm/Nav, but not limited to those.
However, if you go to any of the majors, they'll also start with a standard bus; they just don't market that part heavily because the value/money is elsewhere. I doubt there are very many commercial sats/payloads built on a one-off/custom bus these days. Those that are most likely are relatively high volume (e.g., GPS, Iridium, etc.). (Hughes started doing that long ago for comm sats).
It's uglier than you can imagine.
IIRC (sorry, it was long ago)... on the Pioneer 10//F 11/G missions Van Allen spec'd the Geiger Tube Telescope for an order-of-magnitude more than expected, and we pegged them. Pioneer suffered significantly--never regained full range on one channel of the IPP (Imaging Photopolarimeter--that thing that made the pretty pictures possible).
We nearly lost the spacecraft due to some spurious crap/commands during periapsis on Pioneer 10/F. Try dealing with an idiot-savant-brain-damaged-two-year-old throwing a tantrum with ~90-minute round-trip light time at 256-1024bps. It's ugly.
The running joke was... If you want to be absolutely certain a spacecraft is sterile, just make a flyby of Jupiter. Jupiter's belts are not to be taken lightly. A seriously understated quote from one post-mission presentation "Closest approach: It’s hot in there!"
It's not just hot, it's a red-hot-poker enema in your electronic guts. That Pioneer 10/11 F/G--the epitome of cheap deep-space exploration--survived those encounters and lived to tell--and did so for many more years still amazes me.
It is a testament to what we can do, and what deep-space exploration is all about. (So allow me a bit of hubris: Suck eggs Voyager... you had a much bigger budget, you got the press, you got your name in a Star Trek movie, but we were there first. Nah nah nah.)
Hogwash. The US may has been dicking around, but others haven't. Your comment typifies everything wrong with the typical US attitude to space exploration.
The Russians were in space almost continuously from 1971 onwards--from Salyut, through to Mir and then the ISS--running manned missions and supply flights almost continuously until the present. The only pause in the Russian program was a couple years between the time Mir came down and the first ISS module was put up (again, the Russians).
From 1971-present the US couldn't put a man in space for years over several periods: after Skylab; after Challenger; after Columbia. Meanwhile, the Russians continued to grind along, slowly but surely, providing both manned and unmanned supply flights. Those Progress and Soyuz flights that helped keep the ISS alive? Those were from Russia, using proficiences they developed during the 20+ years *regularly* servicing Salyut and Mir and maintaining a manned presence in space.
Check the total time in orbit for the Salyut and Mir, days inhabited, and the number of missions--it's pretty damned impressive. And that was long before the ISS or the Shuttle.
They weren't "dicking around". They were doing serious science on long-term manned missions, and what it takes to sustain an effort, especially from an operational/practical perspective. It's no accident that a lot of the practical ISS LS systems are based on what the Russians learned and developed. NASA has refined some of those systems, but a lot of the basic tech (air revitalization, toilets, etc.) came from the Russian program.
This isn't a "race", at least if you're interested in more than flags and boots. It's learning. It's exploration not just of places, but of systems. It's engineering. It's figuring out how to make people and machinery work in environments that are hostile and for which many effects are little understood. You do that by trying, correcting, and trying again. That takes time and a sustained effort.
Good for them. Nothing really new here, but someone has to make it clear that we aren't going anywhere much beyond the atmosphere on a sustained basis without nuclear power in space.
That includes space guns, space elevators, and whatnot--you need a tugs ("orbital transfer vehicles") to collect all those cheap/dumb parcels and deliver them to where they're needed. Or you use larger/smarter and more expensive vehicles with automonous maneuvering systems (which is what we do today), and which is why (*cough*) $5-10K/Kg-to-LEO turn into $20-80K/Kg of net payload (usable payload minus delivery vehicle structure, guidance, propellant, etc.
Advanced propulsion (e.g., hall-effect/ion/vasimir/thermal) with solar electric power might be OK for slow orbital or cislunar tugs, but are limited due to mass penalties and array degradation. Such systems need power to get anywhere in a reasonable amount of time, and the more power (in general) the better. Fusion? Maybe someday.
If we in the West can't manage to swallow our aversion to nuclear power in space (real power, not RTG's), then we will cede space to those who will, whether Russia, China, India or whoever. Maybe when they esablish a sustainable LEO and cislunar system (or a Mars effort) using nukes people will wake up (Sputnick redux), but I won't hold my breath.
Pick your poision... Very limited and occassional manned exploration using chemical propulsion, or a long term and sustainable effort using nuclear power/propulsion. I'd prefer the latter.
Good luck, and more power to them.
1. In round numbers:
. ~9.5 km/sec to LEO (given, approximate)
. ~6.0 km/sec from gas gun (FTA)
. ~0.5 km/sec atmospheric drag (FTA)
= ~4.0 km/sec needed from projectile rocket
. 350s ISP for projectile rocket (assumed, optimistic)
= 0.69 propellant fraction
. 450Kg projectile (FTA)
= 310Kg projectile rocket propellant
= 140Kg projectile non-propellant
. ???Kg projectile structure, motor, etc.
= ???Kg net cargo to LEO (in any case, 140Kg)
2. Assuming you want to rondezvous with something in an established orbit (e.g., the ISS), any significant orbital maneuvering is out of the question; in paticular an orbital plane change--whether by the projectile or the target--as it's too expensive.
That limits the number of launch windows. You can't simply launch projectiles into orbit as fast as the gun can fire, otherwise you'll end up with them scattered in various orbits that you have to chase down (again, very expensive).
E.g., there are nominally 2 launch windows/day for Shuttle flights from KSC to the ISS. (Due to various rules, in practice it's limited to 1/day, but we'll ignore that.)
3. Even with optimal launch parameters, orbital rondezvous is still non-trivial, and one reason why even unmanned ISS resuplly vehicles are much more than simply a dumb ballistic container, and have, e.g., OMS and RCS motors, propellant and the weight/complexity/cost penalties that come with them.
Which is why larger, more infrequent and expensive missions will remain the norm for the foreseeable future--with or without a space gun or its ilk.
4. In short, we need an orbital infrastructure that can handle smaller/dumber vehicles. That doesn't exist, and few if any of these proposals account for it. With, e.g., a group of ion/electric tugs it may make more sense. That is, something that can cost-effectively collect those smaller/dumber vehicles and bring them to where they're needed.
The transporter has a service ceiling of 15,000 feet with Shuttle attached, that would given them an additional 6.4PSI of differential. With the other methods (and a bit more altitude if they can manage it, even for only a short period), it might be close enough.
Beg to differ. (Maybe I'm missing something by not spending more time on the crapper or in the tub reading. I just don't get the appeal.)
b rary
I have a huge library of conventional books (about 2K volumes). I have been getting rid of them in favor of ebooks whenever possible. My ebook library now runs to > 150 purchased. (Still mostly SF though because it's hard to find ebook replacements for a lot of my conventional titles, especially non-fiction; SF is about the only fiction I indulge in.)
When reading an ebook I am at my computer, and most of the time Internet connected. I can click on a word or phrase and google it. I am addicted to it. When I can't do that conveniently, I feel deprived and annoyed. Yes, I own dictionaries and encyclopedias, but the Web is often far more informative, convenient and fun. Especially for esoteric content.
I also find it much more convenient when traveling to carry reading material on my laptop, rather than having to lug pounds of paper around (an 18hr flight takes a *lot* of pounds of paper). Especially for "disposable" content. And I no longer feel guilty about dead trees. Then again, the inability to donate an ebook, as I normally do with conventional disposable content when I'm done with them, is one of the very few downsides of ebooks.
p.s. Stay away from "protected" ebooks. Pain in the a**. And if you're into SF, check out Baen, who has not only a large number of volumes for sale, but also a significant "free" library. (And you can get them in a very nice HTML format so you can read them on just about anything). See:
http://www.baen.com
http://www.baen.com/li
What's mine is mine. What's yours is negotiable.
It was originally intended to illustrate various Java technologies and the application of those technologies. It was intended to be a *teaching* tool.
.Net programmer can do it so much more efficiently.
.Net.
To take such an illustrative example, rearchitect it, then make any claims about efficiency, is/was ludicrous. Like taking sample code out of a book on Java, and then showing how an expert
Do some more research and you'll find that the Petshop project has been completely discredited as a comparison of Java and
Proprietary compression. Proprietary "encryption"? (They don't say enough to make a determination.)
I would typically use those features to archive sensitive information. And the when the drive breaks, or they stop supporting it, I'm hosed.
Thanks, but no thanks. I'll stick with standard compression/encryption tools.
That's a great example of where technology can have a really bad effect on a sport.
:)
I loved fencing in a previous life. But I really hated electrics for the reasons you state... strategy went out the window and every engagement seemed to turn into a kamikaze blitz.
My only solace is that if it had been real swordplay, I might have come away with a few nicks, but my opponents would have looked they had been run through a Quisinart. (damn that was fun. and i'm one of those pr*cks who always used a *really* stiff blade.
...is still inversely proportional to the weight of your bike. Alas, with all this progress, all bikes still weigh 50 pounds:
- A 49-pound bike requires a 1-pound lock.
- a 1-pound bike requires a 49-pound lock.
You're correct that trustable code would be a benefit. However, a trusted computer and software is only one component of a much larger and more complex process--that entire process must be secure.
:)
An example is (or was) the Nevada Gaming Commission's requirements for electronic games. It's been a very long time since I had anything to do with that--I was involved when electronic games were first being considered--but the requirements being discussed then were draconian. Wxtremely strict auditing requirements for everything from software development through to operation of the system and physical safeguards. (We use to joke that getting a C2 certification was easier.
I looked through the document Ryano pointed at in a previous post. In short...
There are two different parts to the system:
1. The voting machine, or "IES" (Integrated Election System). Proprietary hardware and software (68000-based).
2. The Windows workstation that runs the "EMS" (Election Management System). That is used for "personalizing" the IES and tallying the data from the IES.
The doc is primarily concerned with the IES, which requires 120KB of EPROM; they state the size of the source is 1.1MB.
So it's doubtful the IES firmware is anywhere near 200,000 lines. The EMS, with a bunch of fancy UI and database stuff, may very well be 200,000 lines.
The web site and source code for the Australian system referred to in the article is worth a look.
It's quite simple. Intentionally, as the ACT states in their design goals (http://www.elections.act.gov.au/EVACS.html). The source includes the client and server application components--160 files and 12739 lines of very straigtforward C. (Of course, that doesn't include the OS/libs.)
I've browsed through a fair bit of the code, and everything I've seen is GPL. Ensuring accessibility to software used for public elections is, I think, a Very Good Thing. (I wouldn't mind seeing a law that required all election software be GPL'd.)
Cool -- thanks for the info.
It looks like what you suggest would be most successful in a situation where the users don't roam too far, and have a limited set of functions that need to be performed. I think that describes about 90% of the typical office environments. (I never thought of using CD's--have to think about that some more.) However...
Scaling into the thousands probably requires a very different animal. That has been done with UNIX and appliances (diskless workstations, NFS home/work directories, etc.) for years. However, there's a significant investment in network and infrastructure required--the network has to be extremely reliable and provide very good performance. That's not an insurmountable barrier, but I don't think many networks that are Windows-centric have the reliability/performance required. (I have no quantitative data, just anecdotal evidence.)
One of the most significant barriers is not the administrative side, although it is reflected in adminstrator's views: user's fear of losing "their" computer (for whatever reason--and there are many) is an extremely difficult barrier to overcome. Unfortunately we get into a vicious cycle, as a less reliable or lower performance network/infrastucture reinforces the desire by users--especially "power users", and those with the $ authority--to retain a desktop system that can operate autonomously. And most of those users also use laptops and roam between offices.
In short, making the leap from where organizations are today with a conventional PC-per-desktop, to a diskless/appliance desktop model seems to be too large for organizations to take in one step. That we'll eventually get there I have no doubt. It's the in-between step that seems to be a problem. Who knows, MS's pushing "smart displays" may do it. (And wouldn't that be ironic.)
p.s. I'm not, nor have I ever been, a Windows admin. I advise clients on solutions for enterprise IT problems. A fundamental problem is that clients often state problems or requirements with a pre-conceived notion of the solution space. ("You say you need a car that goes 600mph? Wouldn't an airplane be better? Oh, you've never heard of airplanes?") Your characterization of that as lack of imagination is correct, but that's more often than not what we're dealing with.
Ok, since you seem to lack the imagination required to interpret "desktop" outside of a narrow and preconceived context, I'll try to be more specific...
"Zillions of end users using Linux as their primary application platform in an enterprise environment using X." Where you can fill in "X" with your choice.
The idea of network appliances, which is basically what you are suggesting, or their equivalent, is not new. I am intimately familiar with them. And the issues that have kept them from wide scale adoption. (And I suggest you climb off your high horse and study those failed deployments before throwing insults around.)
If that is your suggestion--and your experience, wonderful. We'd also like to know you got buyin. And how you manage the resulting deployments.
But please... If you have something useful to add, add it without insulting others.
The study is not specific enough to make a blanket "Linux vs. Windows" claim.
For application servers I think the study is correct, just based on my casual observations (e.g., managing a farm of Apache or Samba servers).
For desktops it's not clear. Active Directory and Group Policy Objects make managing 50K+ desktops feasible. I don't see anything on the Linux side that can cope with that magnitude of desktops.
I sure don't know how to answer the desktop management question when talking about zillions of Linux desktops.
Can someone who has experience with large scale Linux desktop deployments share their experience?
From what you've said, it sounds like your customer is footing the bill for the development. That is typically called "work for hire", and they who hires owns the work.
However, it is not unusual to find agreements where the funder [them] retains a "prepetual, world-wide, right to use license" for the product/IP (which does not include the right to resell, redistribute, create derivative works, etc.); the hiree [you] retains all other rights to the IP.
There are many, many, many boilerplate agreements of that sort floating around. A master service agreement from virtually any large development or consulting outfit will likely contain verbiage you could lift verbatim.
That said, talk to an attorney; they shouldn't charge you much for crafting this type of verbiage, since it's very common.
You can't change the past. But you can draw a line in a non-confrontational way, where you define your future relationship...
,
Dear
Glad I could help out with . As I have demonstrated in the past, I enjoy the opportunity to solve problems and assist in any way possible.
In the event you require additional assistance, I have attached my standard price schedule. I'd be happy to discuss discounts for extended work, or on-call or after hours rates.
I look forward to working with you again in the future.
Sincerely,
132 MB/sec xfer rate -- Nothing to get excited about; it's PCI bus bandwidth limited. I can saturate the PCI bus with RAID (IDE or SCSI) already. I can do better than 132MB/sec using a 64-bit or PCIX RAID controller, which this "drive" doesn't appear to offer.
100,000 I/Os per sec -- That is smokin', but how many I/Os are going to be single-sector reads? You'd be better off with more main memory buffer space to reduce small I/Os, which gets back to the question of xfer rate.
So you end up with a very high priced disk with none-to-exciting xfer rates but excellent seek times. Moreover, it takes up a PCI slot, which limits expandability.
It would make more sense if they make it look like a SCSI 160/320 drive (or array). It would have far greater expandability; still have bus-limited xfer rate; but a slightly higher access time.
It is true if you change the playing field, which is the point of the article.
RIAA+Labels = Promotion + Distribution + Obstructionism
Internet = RIAA+Labels - Distribution - Obstructionism
What's left is promotion. So how do other industries deal with promotion? They use "adverising" or "PR" firms. But those firms don't (and shouldn't) get a lock on the intellectual property associated with the product just for promoting it.
The functions of promotion and distribution will not disappear, but their implementation in the form of the RIAA and labels can, and should, be replaced.
The power to make the change is in the hands of artists. Artists could set up their own alternative to the RIAA and labels at any time. Why haven't they? The technology is a no-brainer.
No, this doesn't address physical CD distribution. But look at the context of this discussion, the debate, and the industry's cry for action against piracy--it all centers around the Internet. That's where the solution needs to start.
Obviously a replacement wouldn't address the back catalogs controlled by the labels. However, once a viable alternative is in place, the labels would probably be much more amenable to rational negotiation.
In short:
1. Construct a viable alternative; then
2. Bring the RIAA & Labels to the table; then
3. Negotiate acces to the back catalogs.
Anything else is wishful thinking--and whining--and requires the largesse of the RIAA and the labels (good luck).
Sometime in the last 60's or early 70's (?) there was research into the relative effiency of innovation and R&D in the U.S. and the Soviet Union. I believe the research was conducted in response to similar concerns about some research being sequestered in the U.S.
While there were many causes cited, one of the most significant conclusions of the paper was that the U.S. was far more efficient because of the openness of the U.S. R&D community. Specifically, that U.S. military research could benefit significantly by adopting a "no secrets" approach. (As you might imagine, that was quite controversial within the DoD community.) And, while the Soviet Union led in certain areas, cross-discipline pollination suffered, as did application.
All this should be intuitively obvious to anyone who's watched ideas spread and grow, which fosters a virtuous cycle, which is inhibited by secrecy. I'm sure other research has been done in this area by now, but this was the first time (at least that I know of) that it was taken beyond the "inutitively obvious" stage.
I can't find the paper on the web (my paper copy disappeared long ago), and I don't remember who conducted or sponsored the research, but the findings caused quite a stir and debate which is why I remember it. If anyone out there has a solid reference, I'd very much appreciate it. Thanks.
One of the first things I did when I took on the responsibility of managing a dev team was to hire a librarian. (A real, trained librarian, not a "code librarian".)
It was the best investment I ever made. It didn't take long before virtually everyone's first stop with a question was the library/librarian. Reference material, competitive info, standards, you name it... the librarian knew how to take piles of information in whatever form and organize it, make it accessible, and make it far more usable to everyone.
If you have a dev group of more than 15-20, your dev group is wasting time and money by not having a professional librarian on the team. It's a job that's part administrivia, part science, and part art. I have yet to find any other discipline that blends those parts as effectively as library science.
(I have to admit I've always had a soft spot for librarians, probably because I spent so much time in libraries. I have also been extremely impressed by librarians understanding of applying technology for information management, and the very progressive ideas that came out of library sciences. That doesn't always translate to high tech libraries or systems, but that's more often than not a funding issue.)
I understand plantation mentality. But I don't buy it--at least not completely. So I'll ask the question differently:
...when without the buy-in of the artists, any alternative is doomed to fail?
Why should I, or anyone, shed any tears over the artist's "suffering", and complain about the label's or RIAA's mistreatment of the artists...
Why should I, or anyone, shed any tears over the the label's or RIAA's intrasigence when it comes to innovative distribution models...
Mind you, I'm not convinced one way or the other, which is why the question was posed to an artist who is familiar with the RIAA.
I'd really like to know what the impediment is. Is it really a plantation mentality as you suggest? That artists don't have a sufficient grasp of the technology to understand the alternatives? That the labels/RIAA have some other power that prevents such an alternative?