I am under the impression, that besides protocol compatibility, a World Phone, would also need to be able to send/receive on all the different frequencies used around the world (900 MHz, 1800 Mhz, 1900 MHz). Is that that easy to do? For example, the Ericsson euro-GSM phones (for 900 MHz) have considerably smaller antennas than their American (1900 MHz) counterparts.
Any DSP people out there to confirm/shoot down this?
With my little Beowulf-building experience, I have to say I agree with you; not only, a specialized "cluster node" kernel isn't a bad thing, it's probably a needed step: e.g. cluster nodes need not be too picky about security/authentication when talking to their 'master node', since that's all they talk to. We already have so many patches to deal with, it's unwieldy (TCP patches, memory patches, unified process space patches, etc...)
As long as (a) the changes are made public (and the GPL so far has ensured that), and (b) the 'cluster' kernel follows (closely;-) the tech advances of the main kernel (e.g. SMP, a sore point so far in clustering) we should be ok...
oops... I just read the post more carefully... well, I have no experience with diskless nodes; that certainly would make a lot of sense for a number of reasons...
Video cards: if you want to use a KVM switch for administration, you'll need them: in that case, go for cheapo cards for the computing nodes, and get a top-of-the-line one for the front node.
I recently saw VA Linux's set-up for a linux cluster: their kick-ass feature is administration thru a serial console (no need for more expensive KVM switching) and direct manipulation of each node's BIOS from the front-node (no cpu cycles spent on that). OTOH, I wasnot impressed by their top specs on their 2U systems (2 PIIIs, 1 GB RAM total): some of the code I am porting needs ~1GB/CPU, and that's not a top-of-the-line code either. Plus, 2-CPU systems mean more rack space (as opposed to quads); however, SMP performance under Linux still has a long way to go, so YMMV...
A final note: be careful about disk I/O: the common solution on MPP machines is to have each process write to disk; in linux clusters, this usually means writing to some NFS-mounted partition. Well, the NFS implementation (and I am not sure here if it's NFS in general or linux's version) cannot keep up with a lot of reads/writes to the same space... Change the way you do I/O (one process handles everything) or clone the filesystems and use local space (a bitch to maintain, though)...
Beowulfs are cool, but we are not nearly commercial-level usability here... what did the old maps say, "monsters here"?;-)...
Look at the Beowulf Underground for an excellent compilation of links, resources and software.
Also, if you're not gonna need some of the more specific software (kernel patches, ethernet channel bonding and the like that usually come in RPMs) but just want to implement generic MPI or PVM, I'd go with Debian next time instead of RH6.0, purely for maintenance reasons.
The big question you have to ask yourself though, is what kind of application you want implemented, and build the cluster to match it... if you don't have an application in mind, then you probably don't need a Beowulf...
The combined force of Java servlets on one hand, and content/presentation separation of JSP (and maybe XML with Cocoon, which I haven't really played with yet) seem to me like an ideal e-commerce solution, as any existing infrastructure can be tied to a Java API these days.
But, as much as I appreciate the work of the Apache Java people, I believe an extra layer of abstraction is needed, a web-application Java API. Wouldn't be nice if any score of developers and small companies could sell/license specialized Java classes that could be dropped in the same web-application framework?
I'd really like to see a company that would support such a standard, collect and standardize the different classes, and compensate the developers appropriately. So, for example, a small company could develop a shopping-cart class. Then, the 'brokerage' company would tie in this class with the rest of the application and sell the entire application to a client, providing support: the developers of the shopping cart class would get a pre-agreed-upon share of the sale and support fees. And of course, to create more competition they could also license the same class to any number of 'brokerage' companies...
Does anybody else out there want something like this? It's not exactly open source, it's more like open API/standards, but hey, small-time developers have to eat too;-)...
What? has noone else got a boxed Debian yet? VA Linux was giving them out at ALS on the hour every hour (at least they were Thursday).
Nice yellow box with the big swirl on it and the logos of VA, O'Reilly and SGI. And it comes with an O'Reilly book "Learning Debian GNU/Linux', 1 CD and a bumper sticker...
Favorite quote on the box: "Never buy software again" (talking about apt-get).
Even if it increased the distance by 20%, your idea will still counter the maglev-rail savings: by taking off at a much smaller angle than 90 deg. (say, 45) you're gonna have to deal with a proportionally longer segment of high-density air at lower g.
The limit here is air density: a) because it increases drag (from friction, if nothing else) without adding lift (as it does in aircraft), b) because it will *disproportionally* increase the fuel mass required --which is sort of a positive feedback loop: the more fuel you need, the more fuel you need to carry that fuel).
In other words: if you're gonna use a maglev-anything to improve cost efficiency, you're gonna have to take off at near-90 deg. And something else: the higher the speed of the craft on leaving the rail, the harder it will be to re-orient it for the appropriate orbit --although I doubt that's a concept-killer.
Don't disagree with your math; But, you have failed to consider safety: that vehicle, going at about Mach 1 close to the ground (and required to make a 90 degree turn upward) will still have to carry rocket fuel; even if it's solid fuel, it's not the safest configuration you can have;-)....
And, BTW although the 'first mile' of the launch is the most expensive energy-wise (more mass, higher g, higher air density), Mach 1 (~600 mph) is about 1/24 of req'd escape velocity...
I don't have the maglev gun performance numbers handy, but I doubt this technology will make a *practical* space launch vehicle. For one thing, imagine the infrastructure involved with building a maglev rail on the side of a decent-size mountain (to get the altitude and structural strength required to launch a cargo-bearing craft). Plus, you still have to have a rocket for the rest of the way up.
OTOH, there exist propulsion technologies that require minimal to no infrastructure and are probably safer (think of the poor safety people having to deal with rocket fuel being propelled at Mach 1 (~600 MPH) up the side of a damn mountain!;-).:
Linear Aerospike engines (what the X-33 will use). Basically they optimize rocket performance for any given altitude, making for a far more efficient launch, and enabling Single-Stage-To-Orbit (SSTO) vehicles that are lighter and smaller.
Aerial Rocket Refueling. Also known as "Black Horse"Technology which is far crazier than the aerospike and far less safe, but it'll probably be cheaper if it gets off the ground (pun not intended).
Alternative SSTOs like that rotor-rocket (the name of the company escapes me) and the McDonnel Douglas (I guess Boeing now) Delta Clipper.
ICBMs... didn't the Russians recently launched a LEO off a damn silo?;-)....
Maglevs are cool, but IMHO rail-guns will be a lot more useful for what the Army *really* wants them for: high-speed anti-armor projectiles, as in tank canons... guess with those Lithium Polymer batteries, they might be able to pull that off;-)...
So you could store the sales history of every product sold in every store of a national chain (say Sears) in any given time interval.
Then you can do things, like identify regional trends in sales, inventory optimization, etc.
Of course, we're talking TBs of data, and hardware and software designed for speed;-)
You could theoretically do everything in C/C++, but I doubt anybody does that: you need very, very fast access to the data, which is usually done by a proprietary app/language (which is what the post is looking for). Then you can build application logic on top of that in anything you want really...
Short answer: No. Multi-dimensional databases means you have n sets of 'columns' or 'rows'. I.e. a regular DB (e.g. Access) which divides its tables into columns and rows is 2D, strictly. An nD DB would have n-dimensions *each* divided into 'columns'.
BTW, An open-source nD DB would kick-ass. But it has to be geared for *very* fast read access times...
It's not that simple: as an aerospace engineer, I have to excuse the NASA people somewhat: the US system is entrenched in the aerospace industry. Other fields may use 9.81m/s^2 exclusively, but for us 32ft/s^2 is as common, if not more. Add to that that for some numbers, US is more convenient (e.g., speed of sound ~1000ft/s) and, even worse, that most of the aircraft instrumentation is in US/English (because of the near total domination of the world aerospace industry) and things are even more screwed up.
Having said that, I still think NASA should take a close look at their QA procs: this is not a new problem by any means...
It's not as simple as that; aeronautics and aerospace traditionally use US/English units (because of the dominance of the US --and English-- aerospace industry). So, you get a lot of (older) engineers who can only think in English, plus a lot of look-up tables and software using metric (never mind aircraft instrumentation, etc).
There was even a near-airccraft accident some years back because ground personnel filled up an airliner's fuel tank reading the gauges in gallons, while they were in liters.
Unit conversion has always been a problem, something like this was bound to happen; that's why some of us write hacks in Javascript (shameless plug;-).
Mutlu was a regular poster in several of the soc.culture.* newsgroups, back in '92 or so... he would post dozens of really long posts per day on certain subjects and would reply to any post that touched on these subjects...
In '93 or so, it was wildly rumoured that Mutlu as really an AI, a script that parsed the soc.culture.* hierarchy. At about the same time, I stopped following s.c.*... Anybody know what came of that??
I am probably gonna get flamed for this... I don't believe that Free Software is about Freedom. Freedom is a very, very important word to be used for anything materialistic , i.e. redundant (think of it this way: would you rather live without software or without freedom?).
Having said that, I thingk that Free Software makes sense; it ultimately brings the good engineering practices of other specialties (mechanical, electrical engineering, etc) to software. Case in point: if Mr. Benz (one of the earliest internal combustion engine makers) made his first engines in such a way that the mechanics were hidden from the outside, would we have the same level of automotive technology today? I doubt it. Free Software allows software engineers to adapt other people's work to their own, much like 'hardware' engineers can...
By extending this one step further though, you can argue that Free Software is ultimately capitalistic: it levels the playing field for any newcomer to adapt existing technological infrastructure and enter the market succesfully (and, most importantly profit personally from it).
OTOH, a software monopoly, like MS's is much more like communism: a central, 'benevolent' authority distributes the same service/goods to everybody, making everybody 'equal', making the quality of the services/good irrelevant.
I also proposed something similar to another thread. I doubt that meta-moderation will help too much; the same problem is bound to recur again and you're gonna need M3 moderation (this of course, assumes that/. will keep growing at the same rate;-).
Instead, I say get rid of moderation as it stands now: go totally peer-review. Give *every* registered, logged-in,/.er say 5-10 moderation points per day. Then allow us to vote each post up or down only (and only one vote per post per time).
This will mean that posts might get scores of +/- 50 or 500 or 5000 even, so instead of making thresholds absolute, make them proportional (say, show only posts that in the top 5, 10, 30, etc. percentile of points).
That way your SQL will get uglier (and the server will get slower;-(, but it should work for any number of users, and it will eliminate successive review of reviewers.
Back in my Army days, we were looking for a device like this to distribute documentation in factories, hangars, airfields and the like. $500/pop ain't that bad if you consider the costs of archiving, sorting, updating, copying and distributing tens of thousands of pages of documentation.
You can certainly take over that market if you demonstrate a coupla extra capabilities: * Security: Although documentation isn't exactly classified material, any military organization or large company would want to feel like there is some security. * Ruggedness: The device should probably be water-proof, shock-resistant (1m drop?) and probably resistant to some chemicals too (like aviation-grade fuel, etc).
Feel free to contact me for consulting purposes:-)...
I like the "in progress" idea... sort of a queue, huh? But also I like/.'s turnaround time. A coupla features that might be more useful:
* Allow logged, registered users to up/down any post *once* (just stick a radio button next to it). Instead of filtering/moderation, give us the option to see posts that have been upped by xx% of the users. Of course, you'll need more SQL boxes for that one;-)...
* Thread articles as well as posts. E.g. this article would be the next in the RH Trademark thread, and so on...
Just a clarification on your observations about fly-by-wire systems on aircraft. I think you are confusing the need for fly-by-wire systems with the need for flight stabilization. Meaning: some modern fighter aircraft (most notably the Mirage series and all Stealth aircraft) are inherently unstable in flight --i.e. they cannot maintain level flight on their own or under human control. Enter active control systems which stabilize the aircraft by feeding a huge number of command inputs (turns, pitches, thrust fluctuations) to the flight system: these inputs cannot be controled/sustained by either a human or any sort of mechanical device. This is why FBW is necessary in a lot of combat aircraft.
In civil aircraft, OTOH, fly-by-wire is being adopted (mostly by Airbus) because it's cheaper: instead of running 2 and 3 lines of hydraulics throughout the plane, you run 2 FBW (and, coming up, fly-by-light) lines and 1 hydraulic as a backup. FBW has become affordable because it has been used (and understood) in military machines.
Redundancy in aircraft systems is not because engineers do not understand/trust the control code, but because this is how aircraft are built. Any aircraft is built to at least 125% to 150% of the needed specs (so say, if the strongest recorded cross-wind is, I dunno, 60 mph, an aircraft will be designed to accommodate 90 mph). And for vital systems/parameters this margin (of safety, not error) goes up to 200% and 300%.
I am sure that when and if GAs become good enough to be put on planes, they will be --aerospace firms are traditional early adopters-- but there will always be a backup.
Next time you fly an airliner and the passengers applaud the landing, thinking they are congratulating a pilot, know that most likely the pilot was a backup for a real-time autopilot system;-)...
This is total nonsense, since the reason the pressure is lower on top is that the surface area is greater, and the total force integral must be the same if the air isn't to be displaced, so in fact lift due to Bernoulli's principle is precisely zero.
Hmmm... most subsonic airfoils have actually larger surface area on the bottom side of the airfoil. The reason airfoils produce lift is because of the difference in momentum between the two flows (top vs. bottom), mainly caused by varying airfoil curvature. And this only holds for certain speed regions and dimensions (Mach and Reynolds numbers). This explanation is not in any way a product of "new methods" or models. It's taught in any aerospace school worth its tuition --and I sincerely hope these two posters aren't aeronautical engineers...
Also, CFD (computational fluid dynamics) is based on existing physical models of fluid mechanics, it doesn't conjure them up from silicon.
BTW, to the previous poster: the stuff about bumblebees is the second most often-told myth in aerodynamics (the first being that lift is produced because air has to travel over a longer distance on the top surface --basically, what the above post is saying). Bumblebee flight defies aerodynamic explanation for regions of Reynolds numbers (i.e. rougly, density and length) that airplanes fly in, not bees.
Please refrain from spreading FUD about aerodynamicists;-)
I was involved in Georgia Tech's Hybrid Rocket project --which mooched off both NASA and AMROC-- 4-5 yrs ago. Since we received neither money or tech assistance ('xcept some spare fuel pellets) from either, I ain't bound by an NDA;-)
It's been a long time, and it's not my field any longer, but I am under the impression that the biggest drawbacks of hybrids were: a) Unpredictability of the burn rate thru the fuel cell --basically rubber cannot be made at a uniform consistency. Rubber chunks may get injected in the exhaust flow; also temperature and pressure will not be uniform, causing unpredictable flows thru the nozzle, and possibly local shocks along the flow. If I went on to a PhD, my work would've been to computationally model the core to predict this behavior. b) The exhaust fumes are very, very bad (like tires burning, but 1000s of times worse) c) The motor is basically not very efficient, at least not anywhere nearly a solid or a liquid; since the core doesnot burn uniformly (and even if it did, the core pattern cannot be made in such a way as to prevent chunks from entering the flow), the core isnot burned 100%. I recall efficiencies of the order of 85% (compared to 97+% for solids and 99+% for liquids)
Most stock-option slaves are out-of-college twentysomethings. Most H-1B slaves are out-of-grad school thirtysomethings, a lot with wifes and kids. Unemployable wifes and kids, either because of language skills or legal limitations, or (often) both.
Stock-option slaves know the culture, society, the rules of the game. They choose to be in the game and stay in it. H-1Bs may choose to take the chance, but once in it, it's not that easy to leave. You built up credit debts (which are impossible to pay in USD if you move back to say, India, and make 1/10th the amount of money, even for the same level of quality of lige), some countries may look down on you (say, China, Iran, Syria) for migrating to the US in the first place, etc.
Stock-option slaves have rights; they can leave and return to the US at will. Not so with H-1Bs. You need a Multiple Reentry permit, which in itself isnt too hard to get, but it costs time and money.
Stock-option slaves pay Medicare, Medicaid, Social Security, and can expect to get coverage. Not so for H-1Bs, unless you invest the 5-10 yrs to get a Green Card and claim that coverage. Yet, the fees are still deducted from pay...
Finally, I though/.ers for one would realize that foreign tech workers increase the damn salaries, not decrease them. The fact that there are people willing to come to this country and work, even for 40-50% of the national average salary of their peers, keeps the industry in the US.
Get your heads out of your cubes people: look at the automotive industry, consumer electronics, clothing, agriculture... If the US makes it harder for people to come here, they will stay at home. In the age of the Internet it doesnt matter much anyways... Can your SF-lifestyle-paying company compete with an outfit out of say the Czech Republic, Bulgaria, Russia, India? These guys can charge $1,000 for a site license, kill the US-based competition and still live a life of luxury at home... Yeah, that's the way to keep your salaries, close the doors... And this from Open Sourcers...
Wow... that post really struck a nerve. I've been an H-1B worker here for the past half year. The article is 100% correct and actually has left out a coupla of important factors.
What usually happens (in my experience at least) is that H1-Bs are usually recruited out of grad school or, less often, over the Net (as I was). Now, most, if not all H-1Bs, either have no experience of life in the US (including cost of living, job market, work ethic) or very little --usually what you get in grad school; but most science and technology grad schools these days have, in the majority, foreigners anyway, meaning there aren't that many Americans around to pass on cultural/social/financial experience to us foreigners (what about a post about the F-1/GRA slaveshops run by most big research schools?)
Now, another factor that that the article left out: most companies don't want to go through the H-1B sponsorship routine, unless the candidate is a really good fit: immigration lawyers cost real money (and you're gonna need one) and most importantly it takes a long time. In my case it took 4 months after accepting the job offer; for some colleagues it took up to 6.
This is because what no H-1B article anywhere has mentioned: INS is forced to deal with double or triple the number of H-1Bs with NO increase in personnel or change in regulations. The usual time to get an H-1B (4-6 weeks) has effectively doubled and tripled after the quota changes and INS was NEVER that good in keeping up with the paperwork anyway. Now the delays have become so long that most big companies shy away from H-1Bs, unless, as I said, it's a really good fit.
Enter, the "slaveshops": contracting or consulting firms that need a lot of good, educated people, and work on slim profit margins anyway. You have all those F-1/J-1 (college students and exchange visitors or researchers for those not-in-the-know) graduates who see the burgeoning economy and most of the time get the door slammed to their faces. With all this opportunity around and the dearth of opportunity back home, sure, why not take a job that pays 30-40% lower than the national average, especially if you don't know that you're worth more? In one company I know there are still US-educated engineering PhDs (from big-name schools no less) on H-1Bs that make less than $45k/yr...
So, why don't they jump ship and switch jobs? For one thing, the H-1B "transfer" process is long and tricky --again, most companies don't wanna wait 2 months to get someone on board unless it's a good fit. Secondly, and IMHO more importantly, most H-1Bs don't have a grasp of the job market or the practices here in the US. In a lot of cultures, you just don't leave your employer after a few months or a year; most just wait until the first 3 yrs to apply for a Green Card or look for another H-1B (you can only get two 3-yr terms) which really doesn't change the situation.
I was more lucky than most, I came here as an undergrad, I understand the culture and all that, but I still had to win the damn Green Card Lottery to get out of the H-1B rut... Most people don't win the lottery, and actually most aren't even eligible to apply (e.g. Indians, Chinese, Koreans). And believe me, did my job options change when I put "Permanent Resident" (i.e. Green Card holder) on my resume... I am leaving my position for a job that pays about 50% more than what I am making now and I could probably have done better than that if I didn't want to stay here much longer.
My proposal for changing the situation: do with the quotas as you (the US Congress, the industry, American people) think you should, but:
Make the H-1B easier to get for qualified, educated workers (no more that inane "have to look for an American that can do the same job" bullshit --most shops will post an ad that precisely fits their fav candidate, down to "has to speak and write Chinese/Indian/whatever"). It makes a lot more sense to set some standards of education/work experience that can be changed according to the needs of the job market, rather than enslave the visa holder to one employer,
Make it easier to transfer between employers --if you aren't here because you fit a specific job but because you're good enough, it should be much easier for you to change sponsors,
Actually have the visa holder pay for the cost of the H-1B process (lawyers and crap) from his salary. Most "sweatshops" use these costs as an excuse for lower salaries anyways, and most big companies shy away from H-1B because of these costs. I, for one, would much rather have $4-5k deducted out of my salary than make $15-30k less than what I am worth.
And please, consider something else: for most of us, cost of living is actually higher than for Americans: most F-1/J-1/H-1Bs don't know the tricks and shortcuts and workarounds to lower costs (unless they stick with a community from their homecountry), most have spouses that have even a worse time finding a job, most have expenses that even for Americans are luxuries (plane tickets to halfway around the world, phone bills that run in the hundreds of dollars).
Something must be done... unfortunately, H-1Bs don't have money to spare to form PACs or vote for anyone to give a shit...
I apologize for the huge post... And thanks that/. is actually shining the light on this phenomenon...
Slashdot Mirror
I am under the impression, that besides protocol compatibility, a World Phone, would also need to be able to send/receive on all the different frequencies used around the world (900 MHz, 1800 Mhz, 1900 MHz). Is that that easy to do? For example, the Ericsson euro-GSM phones (for 900 MHz) have considerably smaller antennas than their American (1900 MHz) counterparts.
Any DSP people out there to confirm/shoot down this?
With my little Beowulf-building experience, I have to say I agree with you; not only, a specialized "cluster node" kernel isn't a bad thing, it's probably a needed step: e.g. cluster nodes need not be too picky about security/authentication when talking to their 'master node', since that's all they talk to. We already have so many patches to deal with, it's unwieldy (TCP patches, memory patches, unified process space patches, etc...)
;-) the tech advances of the main kernel (e.g. SMP, a sore point so far in clustering) we should be ok...
As long as (a) the changes are made public (and the GPL so far has ensured that), and (b) the 'cluster' kernel follows (closely
Just my $.02
oops... I just read the post more carefully... well, I have no experience with diskless nodes; that certainly would make a lot of sense for a number of reasons...
;-)...
Video cards: if you want to use a KVM switch for administration, you'll need them: in that case, go for cheapo cards for the computing nodes, and get a top-of-the-line one for the front node.
I recently saw VA Linux's set-up for a linux cluster: their kick-ass feature is administration thru a serial console (no need for more expensive KVM switching) and direct manipulation of each node's BIOS from the front-node (no cpu cycles spent on that). OTOH, I wasnot impressed by their top specs on their 2U systems (2 PIIIs, 1 GB RAM total): some of the code I am porting needs ~1GB/CPU, and that's not a top-of-the-line code either. Plus, 2-CPU systems mean more rack space (as opposed to quads); however, SMP performance under Linux still has a long way to go, so YMMV...
A final note: be careful about disk I/O: the common solution on MPP machines is to have each process write to disk; in linux clusters, this usually means writing to some NFS-mounted partition. Well, the NFS implementation (and I am not sure here if it's NFS in general or linux's version) cannot keep up with a lot of reads/writes to the same space... Change the way you do I/O (one process handles everything) or clone the filesystems and use local space (a bitch to maintain, though)...
Beowulfs are cool, but we are not nearly commercial-level usability here... what did the old maps say, "monsters here"?
Look at the Beowulf Underground for an excellent compilation of links, resources and software.
Also, if you're not gonna need some of the more specific software (kernel patches, ethernet channel bonding and the like that usually come in RPMs) but just want to implement generic MPI or PVM, I'd go with Debian next time instead of RH6.0, purely for maintenance reasons.
The big question you have to ask yourself though, is what kind of application you want implemented, and build the cluster to match it... if you don't have an application in mind, then you probably don't need a Beowulf...
I recently have been hacking with Apache JServ and GNUJSP.
;-)...
The combined force of Java servlets on one hand, and content/presentation separation of JSP (and maybe XML with Cocoon, which I haven't really played with yet) seem to me like an ideal e-commerce solution, as any existing infrastructure can be tied to a Java API these days.
But, as much as I appreciate the work of the Apache Java people, I believe an extra layer of abstraction is needed, a web-application Java API. Wouldn't be nice if any score of developers and small companies could sell/license specialized Java classes that could be dropped in the same web-application framework?
I'd really like to see a company that would support such a standard, collect and standardize the different classes, and compensate the developers appropriately. So, for example, a small company could develop a shopping-cart class. Then, the 'brokerage' company would tie in this class with the rest of the application and sell the entire application to a client, providing support: the developers of the shopping cart class would get a pre-agreed-upon share of the sale and support fees. And of course, to create more competition they could also license the same class to any number of 'brokerage' companies...
Does anybody else out there want something like this? It's not exactly open source, it's more like open API/standards, but hey, small-time developers have to eat too
What? has noone else got a boxed Debian yet? VA Linux was giving them out at ALS on the hour every hour (at least they were Thursday).
;-)...
Nice yellow box with the big swirl on it and the logos of VA, O'Reilly and SGI. And it comes with an O'Reilly book "Learning Debian GNU/Linux', 1 CD and a bumper sticker...
Favorite quote on the box: "Never buy software again" (talking about apt-get).
It's gonna take over an NT box pretty soon
Kathetos Teleia
Even if it increased the distance by 20%, your idea will still counter the maglev-rail savings: by taking off at a much smaller angle than 90 deg. (say, 45) you're gonna have to deal with a proportionally longer segment of high-density air at lower g.
The limit here is air density: a) because it increases drag (from friction, if nothing else) without adding lift (as it does in aircraft), b) because it will *disproportionally* increase the fuel mass required --which is sort of a positive feedback loop: the more fuel you need, the more fuel you need to carry that fuel).
In other words: if you're gonna use a maglev-anything to improve cost efficiency, you're gonna have to take off at near-90 deg. And something else: the higher the speed of the craft on leaving the rail, the harder it will be to re-orient it for the appropriate orbit --although I doubt that's a concept-killer.
Don't disagree with your math; But, you have failed to consider safety: that vehicle, going at about Mach 1 close to the ground (and required to make a 90 degree turn upward) will still have to carry rocket fuel; even if it's solid fuel, it's not the safest configuration you can have ;-)....
And, BTW although the 'first mile' of the launch is the most expensive energy-wise (more mass, higher g, higher air density), Mach 1 (~600 mph) is about 1/24 of req'd escape velocity...
OTOH, there exist propulsion technologies that require minimal to no infrastructure and are probably safer (think of the poor safety people having to deal with rocket fuel being propelled at Mach 1 (~600 MPH) up the side of a damn mountain!
Linear Aerospike engines (what the X-33 will use). Basically they optimize rocket performance for any given altitude, making for a far more efficient launch, and enabling Single-Stage-To-Orbit (SSTO) vehicles that are lighter and smaller.
Aerial Rocket Refueling. Also known as "Black Horse"Technology which is far crazier than the aerospike and far less safe, but it'll probably be cheaper if it gets off the ground (pun not intended).
Alternative SSTOs like that rotor-rocket (the name of the company escapes me) and the McDonnel Douglas (I guess Boeing now) Delta Clipper.
ICBMs... didn't the Russians recently launched a LEO off a damn silo? ;-)....
;-)...
Maglevs are cool, but IMHO rail-guns will be a lot more useful for what the Army *really* wants them for: high-speed anti-armor projectiles, as in tank canons... guess with those Lithium Polymer batteries, they might be able to pull that off
OK. If in 2D world, the basic structure of a database is a 'table', in nD it will be, say an 'array'. An nD array will be:
;-)
Array: "Sales"
Dimension 1: "Store"
Dimension 2: "Product"
Dimension 3: "Time"
.
.
etc...
So you could store the sales history of every product sold in every store of a national chain (say Sears) in any given time interval.
Then you can do things, like identify regional trends in sales, inventory optimization, etc.
Of course, we're talking TBs of data, and hardware and software designed for speed
You could theoretically do everything in C/C++, but I doubt anybody does that: you need very, very fast access to the data, which is usually done by a proprietary app/language (which is what the post is looking for). Then you can build application logic on top of that in anything you want really...
Plug alert: this is what my employer does...
Short answer: No. Multi-dimensional databases means you have n sets of 'columns' or 'rows'. I.e. a regular DB (e.g. Access) which divides its tables into columns and rows is 2D, strictly. An nD DB would have n-dimensions *each* divided into 'columns'.
BTW, An open-source nD DB would kick-ass. But it has to be geared for *very* fast read access times...
Anything out there?
It's not that simple: as an aerospace engineer, I have to excuse the NASA people somewhat: the US system is entrenched in the aerospace industry. Other fields may use 9.81m/s^2 exclusively, but for us 32ft/s^2 is as common, if not more. Add to that that for some numbers, US is more convenient (e.g., speed of sound ~1000ft/s) and, even worse, that most of the aircraft instrumentation is in US/English (because of the near total domination of the world aerospace industry) and things are even more screwed up.
Having said that, I still think NASA should take a close look at their QA procs: this is not a new problem by any means...
It's not as simple as that; aeronautics and aerospace traditionally use US/English units (because of the dominance of the US --and English-- aerospace industry). So, you get a lot of (older) engineers who can only think in English, plus a lot of look-up tables and software using metric (never mind aircraft instrumentation, etc).
;-).
There was even a near-airccraft accident some years back because ground personnel filled up an airliner's fuel tank reading the gauges in gallons, while they were in liters.
Unit conversion has always been a problem, something like this was bound to happen; that's why some of us write hacks in Javascript (shameless plug
Mutlu was a regular poster in several of the soc.culture.* newsgroups, back in '92 or so... he would post dozens of really long posts per day on certain subjects and would reply to any post that touched on these subjects...
... Anybody know what came of that??
In '93 or so, it was wildly rumoured that Mutlu as really an AI, a script that parsed the soc.culture.* hierarchy. At about the same time, I stopped following s.c.*
I am probably gonna get flamed for this... I don't believe that Free Software is about Freedom. Freedom is a very, very important word to be used for anything materialistic , i.e. redundant (think of it this way: would you rather live without software or without freedom?).
Having said that, I thingk that Free Software makes sense; it ultimately brings the good engineering practices of other specialties (mechanical, electrical engineering, etc) to software. Case in point: if Mr. Benz (one of the earliest internal combustion engine makers) made his first engines in such a way that the mechanics were hidden from the outside, would we have the same level of automotive technology today? I doubt it. Free Software allows software engineers to adapt other people's work to their own, much like 'hardware' engineers can...
By extending this one step further though, you can argue that Free Software is ultimately capitalistic: it levels the playing field for any newcomer to adapt existing technological infrastructure and enter the market succesfully (and, most importantly profit personally from it).
OTOH, a software monopoly, like MS's is much more like communism: a central, 'benevolent' authority distributes the same service/goods to everybody, making everybody 'equal', making the quality of the services/good irrelevant.
In one word, as someone else posted, hogwash...
I also proposed something similar to another thread. I doubt that meta-moderation will help too much; the same problem is bound to recur again and you're gonna need M3 moderation (this of course, assumes that /. will keep growing at the same rate ;-).
/.er say 5-10 moderation points per day. Then allow us to vote each post up or down only (and only one vote per post per time).
;-(, but it should work for any number of users, and it will eliminate successive review of reviewers.
Instead, I say get rid of moderation as it stands now: go totally peer-review. Give *every* registered, logged-in,
This will mean that posts might get scores of +/- 50 or 500 or 5000 even, so instead of making thresholds absolute, make them proportional (say, show only posts that in the top 5, 10, 30, etc. percentile of points).
That way your SQL will get uglier (and the server will get slower
Just my $.02
OK, since you seem to be in the know ;-) :
:-)...
Back in my Army days, we were looking for a device like this to distribute documentation in factories, hangars, airfields and the like. $500/pop ain't that bad if you consider the costs of archiving, sorting, updating, copying and distributing tens of thousands of pages of documentation.
You can certainly take over that market if you demonstrate a coupla extra capabilities:
* Security: Although documentation isn't exactly classified material, any military organization or large company would want to feel like there is some security.
* Ruggedness: The device should probably be water-proof, shock-resistant (1m drop?) and probably resistant to some chemicals too (like aviation-grade fuel, etc).
Feel free to contact me for consulting purposes
I like the "in progress" idea... sort of a queue, huh? But also I like /.'s turnaround time. A coupla features that might be more useful:
;-)...
* Allow logged, registered users to up/down any post *once* (just stick a radio button next to it). Instead of filtering/moderation, give us the option to see posts that have been upped by xx% of the users. Of course, you'll need more SQL boxes for that one
* Thread articles as well as posts. E.g. this article would be the next in the RH Trademark thread, and so on...
Just a clarification on your observations about fly-by-wire systems on aircraft. I think you are confusing the need for fly-by-wire systems with the need for flight stabilization. Meaning: some modern fighter aircraft (most notably the Mirage series and all Stealth aircraft) are inherently unstable in flight --i.e. they cannot maintain level flight on their own or under human control. Enter active control systems which stabilize the aircraft by feeding a huge number of command inputs (turns, pitches, thrust fluctuations) to the flight system: these inputs cannot be controled/sustained by either a human or any sort of mechanical device. This is why FBW is necessary in a lot of combat aircraft.
;-)...
;-)...
In civil aircraft, OTOH, fly-by-wire is being adopted (mostly by Airbus) because it's cheaper: instead of running 2 and 3 lines of hydraulics throughout the plane, you run 2 FBW (and, coming up, fly-by-light) lines and 1 hydraulic as a backup. FBW has become affordable because it has been used (and understood) in military machines.
Redundancy in aircraft systems is not because engineers do not understand/trust the control code, but because this is how aircraft are built. Any aircraft is built to at least 125% to 150% of the needed specs (so say, if the strongest recorded cross-wind is, I dunno, 60 mph, an aircraft will be designed to accommodate 90 mph). And for vital systems/parameters this margin (of safety, not error) goes up to 200% and 300%.
I am sure that when and if GAs become good enough to be put on planes, they will be --aerospace firms are traditional early adopters-- but there will always be a backup.
Next time you fly an airliner and the passengers applaud the landing, thinking they are congratulating a pilot, know that most likely the pilot was a backup for a real-time autopilot system
Don't you wish PCs were built this way?
This is total nonsense, since the reason the pressure is lower on top is that the surface area is greater, and the total force integral must be the same if the air isn't to be displaced, so in fact lift due to Bernoulli's principle is precisely zero.
;-)
Hmmm... most subsonic airfoils have actually larger surface area on the bottom side of the airfoil. The reason airfoils produce lift is because of the difference in momentum between the two flows (top vs. bottom), mainly caused by varying airfoil curvature. And this only holds for certain speed regions and dimensions (Mach and Reynolds numbers). This explanation is not in any way a product of "new methods" or models. It's taught in any aerospace school worth its tuition --and I sincerely hope these two posters aren't aeronautical engineers...
Also, CFD (computational fluid dynamics) is based on existing physical models of fluid mechanics, it doesn't conjure them up from silicon.
BTW, to the previous poster: the stuff about bumblebees is the second most often-told myth in aerodynamics (the first being that lift is produced because air has to travel over a longer distance on the top surface --basically, what the above post is saying). Bumblebee flight defies aerodynamic explanation for regions of Reynolds numbers (i.e. rougly, density and length) that airplanes fly in, not bees.
Please refrain from spreading FUD about aerodynamicists
Linear aerospike engines are way cool. Does anyone know if the X-33 has overcome the flow stability problems of aerospikes?
Now, wouldn't it be cool to put an aerospike on a hybrid rocket?
I was involved in Georgia Tech's Hybrid Rocket project --which mooched off both NASA and AMROC-- 4-5 yrs ago. Since we received neither money or tech assistance ('xcept some spare fuel pellets) from either, I ain't bound by an NDA ;-)
;-) ) confirm or disprove these?
/. ;-)...
It's been a long time, and it's not my field any longer, but I am under the impression that the biggest drawbacks of hybrids were:
a) Unpredictability of the burn rate thru the fuel cell --basically rubber cannot be made at a uniform consistency. Rubber chunks may get injected in the exhaust flow; also temperature and pressure will not be uniform, causing unpredictable flows thru the nozzle, and possibly local shocks along the flow. If I went on to a PhD, my work would've been to computationally model the core to predict this behavior.
b) The exhaust fumes are very, very bad (like tires burning, but 1000s of times worse)
c) The motor is basically not very efficient, at least not anywhere nearly a solid or a liquid; since the core doesnot burn uniformly (and even if it did, the core pattern cannot be made in such a way as to prevent chunks from entering the flow), the core isnot burned 100%. I recall efficiencies of the order of 85% (compared to 97+% for solids and 99+% for liquids)
Can an AC (
At last, rocket science on
Most stock-option slaves are out-of-college twentysomethings. Most H-1B slaves are out-of-grad school thirtysomethings, a lot with wifes and kids. Unemployable wifes and kids, either because of language skills or legal limitations, or (often) both.
Stock-option slaves know the culture, society, the rules of the game. They choose to be in the game and stay in it. H-1Bs may choose to take the chance, but once in it, it's not that easy to leave. You built up credit debts (which are impossible to pay in USD if you move back to say, India, and make 1/10th the amount of money, even for the same level of quality of lige), some countries may look down on you (say, China, Iran, Syria) for migrating to the US in the first place, etc.
Stock-option slaves have rights; they can leave and return to the US at will. Not so with H-1Bs. You need a Multiple Reentry permit, which in itself isnt too hard to get, but it costs time and money.
Stock-option slaves pay Medicare, Medicaid, Social Security, and can expect to get coverage. Not so for H-1Bs, unless you invest the 5-10 yrs to get a Green Card and claim that coverage. Yet, the fees are still deducted from pay...
/.ers for one would realize that foreign tech workers increase the damn salaries, not decrease them. The fact that there are people willing to come to this country and work, even for 40-50% of the national average salary of their peers, keeps the industry in the US.
Finally, I though
Get your heads out of your cubes people: look at the automotive industry, consumer electronics, clothing, agriculture... If the US makes it harder for people to come here, they will stay at home. In the age of the Internet it doesnt matter much anyways... Can your SF-lifestyle-paying company compete with an outfit out of say the Czech Republic, Bulgaria, Russia, India? These guys can charge $1,000 for a site license, kill the US-based competition and still live a life of luxury at home... Yeah, that's the way to keep your salaries, close the doors... And this from Open Sourcers...
What usually happens (in my experience at least) is that H1-Bs are usually recruited out of grad school or, less often, over the Net (as I was). Now, most, if not all H-1Bs, either have no experience of life in the US (including cost of living, job market, work ethic) or very little --usually what you get in grad school; but most science and technology grad schools these days have, in the majority, foreigners anyway, meaning there aren't that many Americans around to pass on cultural/social/financial experience to us foreigners (what about a post about the F-1/GRA slaveshops run by most big research schools?)
Now, another factor that that the article left out: most companies don't want to go through the H-1B sponsorship routine, unless the candidate is a really good fit: immigration lawyers cost real money (and you're gonna need one) and most importantly it takes a long time. In my case it took 4 months after accepting the job offer; for some colleagues it took up to 6.
This is because what no H-1B article anywhere has mentioned: INS is forced to deal with double or triple the number of H-1Bs with NO increase in personnel or change in regulations. The usual time to get an H-1B (4-6 weeks) has effectively doubled and tripled after the quota changes and INS was NEVER that good in keeping up with the paperwork anyway. Now the delays have become so long that most big companies shy away from H-1Bs, unless, as I said, it's a really good fit.
Enter, the "slaveshops": contracting or consulting firms that need a lot of good, educated people, and work on slim profit margins anyway. You have all those F-1/J-1 (college students and exchange visitors or researchers for those not-in-the-know) graduates who see the burgeoning economy and most of the time get the door slammed to their faces. With all this opportunity around and the dearth of opportunity back home, sure, why not take a job that pays 30-40% lower than the national average, especially if you don't know that you're worth more? In one company I know there are still US-educated engineering PhDs (from big-name schools no less) on H-1Bs that make less than $45k/yr...
So, why don't they jump ship and switch jobs? For one thing, the H-1B "transfer" process is long and tricky --again, most companies don't wanna wait 2 months to get someone on board unless it's a good fit. Secondly, and IMHO more importantly, most H-1Bs don't have a grasp of the job market or the practices here in the US. In a lot of cultures, you just don't leave your employer after a few months or a year; most just wait until the first 3 yrs to apply for a Green Card or look for another H-1B (you can only get two 3-yr terms) which really doesn't change the situation.
I was more lucky than most, I came here as an undergrad, I understand the culture and all that, but I still had to win the damn Green Card Lottery to get out of the H-1B rut... Most people don't win the lottery, and actually most aren't even eligible to apply (e.g. Indians, Chinese, Koreans). And believe me, did my job options change when I put "Permanent Resident" (i.e. Green Card holder) on my resume... I am leaving my position for a job that pays about 50% more than what I am making now and I could probably have done better than that if I didn't want to stay here much longer.
My proposal for changing the situation: do with the quotas as you (the US Congress, the industry, American people) think you should, but:
Make the H-1B easier to get for qualified, educated workers (no more that inane "have to look for an American that can do the same job" bullshit --most shops will post an ad that precisely fits their fav candidate, down to "has to speak and write Chinese/Indian/whatever"). It makes a lot more sense to set some standards of education/work experience that can be changed according to the needs of the job market, rather than enslave the visa holder to one employer,
Make it easier to transfer between employers --if you aren't here because you fit a specific job but because you're good enough, it should be much easier for you to change sponsors,
Actually have the visa holder pay for the cost of the H-1B process (lawyers and crap) from his salary. Most "sweatshops" use these costs as an excuse for lower salaries anyways, and most big companies shy away from H-1B because of these costs. I, for one, would much rather have $4-5k deducted out of my salary than make $15-30k less than what I am worth.
/. is actually shining the light on this phenomenon...
And please, consider something else: for most of us, cost of living is actually higher than for Americans: most F-1/J-1/H-1Bs don't know the tricks and shortcuts and workarounds to lower costs (unless they stick with a community from their homecountry), most have spouses that have even a worse time finding a job, most have expenses that even for Americans are luxuries (plane tickets to halfway around the world, phone bills that run in the hundreds of dollars).
Something must be done... unfortunately, H-1Bs don't have money to spare to form PACs or vote for anyone to give a shit...
I apologize for the huge post... And thanks that