I hate to barge in with reality and all that, but governments are usually not profitable. You have profitable government if you run a surplus and you're correctly accounting for servicing of debts, including repayment of principal. Such governments are few and far between. You cannot seriously join "cheaper", "more profitable" with "and", pretending that those are almost-synonyms, or are two faces of the same thing. In real business, getting things for cheap does not necessarily mean that you boost your profits. You usually pay for the cheapness somehow, if not at least in short term profits being reduced by spending on boosting productivity etc. Public corporations have a tendency to trade short term gains for long term demise, too.
Using the word "profitable" with regards to a government agency is pretty silly. An agency like DHS spends money. They don't generate any profits, because they don't bring any real money in. They get some fees and fines as income, but that's not even a drop in the bucket. If DHS were to be run as a profitable business, the true costs of their existence would be felt by every traveller, and there'd be public outrage. You'd be paying hundreds of dollars in fees per every leg of your air travel.
I don't see immediate use for the hypercube, but the individual 1, 2 and 4 core chips are phenomenal for implementing realtime ethernet devices, such as IEEE-1588 switches, realtime industrial ethernet protocols, etc. It's not hard to make a very low latency timestamping switch using one of these. The hardware assisted serialization, deserialization, and time-triggered sampling and update of ports lets you be quite creative because it decouples timing of the I/O with timing of the software. There are many applications where simple MCUs like PICs, or even Parallax's Propeller, are used for software-implements-hardware applications, but those ultimately need cycle counting and you are forced to use assembly. XMOS's XS-1 architecture decouples your software from this, and quite a lot of realtime code can be written in a high level language like C or their quite lovely XC. The latter is a safe variant of C expanded to support transputer communications and hardware-assisted ports. About the only limitation at the moment is the 64kb memory for all code and data, in all threads. Since many realtime applications usually imply little to no buffering, this hasn't been a problem for me, but it needs to be kept in mind. If one wants to have a somewhat slower but larger-memory application code running at a couple MIPS, it's certainly possible to emulate other architectures. ARM Thumb and Zylin Core can be made to work quite reasonably. There's lots of tools that generate code for Thumb, and there's a Zylin gcc port.
No thrusters there. Gyros are the biggest concern it seems, they seem to last well under 10 years it seems. The panels were replaced twice, but those replacements were not due to radiation damage but due to poor mechanical performance and due to undersizing of original panels' electrical output. The first replacement panels were stiffer and would vibrate less when going from sunlight to shade and back. The second replacement panels, of Iridum vintage, were smaller and provided more power, reducing drag and vibration, and providing enough power to run any combination of instruments needed at once.
You underestimate them. They were the first private entity ever to launch a spacecraft into orbit and later retrieve it. First as in first in the world. They pulled off something that only governments could do before them. They did it for slightly more that it cost to build the useless Orion service tower.
The gyros have limited lifetime, and their failure is not some random out-of-the-blue occurrence. They will all eventually fail, well before the entire satellite will be dead.
Even with design for on-orbit repair, they could have launched 2 or 3 Hubbles for the price of one repair mission. If it was to be a throwaway design, it'd probably be more Hubbles per Shuttle launch, but so what.
I wonder what will happen to the final carrier plane. The other one was retired for parts and whatnot, per wikipedia. It probably had not very many cycles nor hours while used by NASA, although they didn't exactly buy it new either.
Space Shuttle ended up being everything to everybody, and when that happens you usually get mediocre performance. Many of its missions made no financial sense. For the cost of the Hubble repair missions they could have launched 2 or 3 more up there.
I agree wholeheartedly. Adjusting e-brakes can be done from the inside of the car in many modern cars, so there's no excuse for not having it adjusted properly. I think that at least Volvo sedans and wagons made in the last decade are all like that.
Button saying P? Emergency? What? Are we on the same planet?
The P setting on the automatic transmission applies a mechanical lock to the driveshaft. Said lock is spring-loaded and is supposed to slip on its ratchet if you happen to engage P while driving. It should normally catch and jerk your car to a stop only when you're going quite slowly (a couple km/h tops). So using the P setting to slow down the car will simply not work. It's designed to hold the car steady when parked, that's all there's to it.
If you have an automatic transmission, you'll use the hydraulic brakes normally, if those fail you can do engine braking coupled with use of emergency brake. If the car is front-wheel driven, you may get by with setting your automatic transmission into reverse at speeds of perhaps 10-25km/h, but you'd better test it under the assumption that it may be a destructive test. You've been warned:) Turning on the reverse applies a large bias to the torque converter, and you can easily lock the wheels if you're not careful with choosing your engage speed. This trick has saved my bacon once, but I'll be glad if I won't ever have to repeat it.
I have. On those the emergency brake doubles as a parking brake:) If it were a parking brake only -- designed to hold your car but not to decelerate it -- you'd really need some other system in case your hydraulic brakes have failed. A parking brake has quite a precise meaning in mechanical engineering. If you have a motor that's part of a big machine and you use its shaft lock brake (parking brake) to stop the machine (even if just to dissipate its stored kinetic energy), you may end up with a fire, and you'll likely need to service the brake to make sure it survived the maltreatment.
That's insane, for a couple of reasons. I don't think that it's even possible to take this cable out in most cars yearly even to look at it up close, without damaging various clips in the process. The cable has to be designed to accept lubrication, too -- you'd need to be able to remove the cable from the liner, or have proper grease fittings to push grease between the liner and the cable. You may have some historical car where the cable is serviceable like you claim, but it won't be the case on any modern car -- the e-brake system is simply not designed to allow such periodic lubrication. Design for serviceability plays a big role here.
It's not a parking brake, never was. It's an emergency brake. I bet most people in the U.S. never bother setting it when the car is parked, heck, many of them I'm sure wouldn't know where it is or how to use it in an emergency. There's a "P" setting on the shifter, that's good enough:/
Any parametric CAD system. Alibre Design would be one example (it is good and cheap, although, sadly, it doesn't run on OpenGL). I have some assemblies that consist of a couple thousand parts. Those parts aren't washers either, even though a washer doesn't exactly have the most trivial geometry. I've been trying to get it to run on wine for the a bit a year or two ago, and I eventually coaxed it to get as far as trying to display some geometry, so I could see how many calls into wine's directx implementation it'd do, and how much data it'd try to push. It was a couple hundred megabytes over a couple tens of thousands of calls.
Never mind that remote screens don't provide any DRI, so if you're using Mesa it probably won't be accelerated even if you have a high-end 3D card on the display. I'd like to be wrong on that one, but I'd think that Mesa needs DRI to use 3D hardware.
A visa is a document that entitles you to cross the border, nothing more, nothing less. It doesn't need much to do with what's your immigration status once you're in the country.
You can own and operate a business in the U.S. even without a visa -- obviously, because a visa is to cross the border and that's it. You can also own and operate such a business without having any immigration status. Heck, you can even without ever having to set foot in the U.S. None of it is illegal. Now, being employed by or rendering services for said U.S. business while also being on the U.S. soil, that's what requires appropriate status with DHS (fka INS).
What I mean by "otherwise known as VNC" is that it is local, and you're transferring bitmaps to the display. It doesn't then matter how the rendering is done (GPU, CPU, black magic, or otherwise).
Good question! No, they'd probably not pay for themselves, at least not due to their broadcast side of operations (vs. web-based). Their days are counted anyway as many young people don't care much about TV, and presumably they won't care any more as they get older. Their clientele is probably 30+ with peak, I'd guess, around 45-50 maybe. I can't imagine too many 20 year olds watching HSM.
Having had access to MFM and having looked about 8 years ago at a then-state-of-the-art hard drive I can tell you that there is no inter-track spacing with anything resembling data in it, unless that particular drive was somehow a special case. It was a rather normal laptop hard drive. Have a look at the relevant wikipedia page. There is effectively noise between the tracks of the old 3.2gb drive, but there's nothing between the tracks of the 30gb drive. A contemporary hard drive has very, very few domains that don't carry data.
3D local to the application is otherwise known as VNC. Render however and whatever, then ship the bitmap to the screen. You don't need any of X infrastructure for that. Even if you ignore the overhead of shipping the bitmap, there's still the overhead of getting the stuff rendered by the local GPU from its memory to main RAM. Such overhead is not present when the GPU renders directly to the framebuffer.
3D local to the display requires that the display and the application (X server and client) are on the same host. Otherwise the OpenGL calls are routed through a remote procedure call system. This would be fine if not for the fact that the OpenGL API horribly suffers from network latency if it's being executed using RPC. It was never designed to be used that way. Never mind that in dense datasets (say complex CAD assemblies), the geometry may well be orders of magnitude larger than the rendered framebuffer, it then makes no sense to do remote rendering on the X screen; doing it locally and shipping the resulting bitmap will take less network bandwidth.
You don't get how it works. The HSN pays the cable companies to be distributed! They are profitable, they have money! They are perhaps the poster child for how it should be done.
Slashdot Mirror
I hate to barge in with reality and all that, but governments are usually not profitable. You have profitable government if you run a surplus and you're correctly accounting for servicing of debts, including repayment of principal. Such governments are few and far between. You cannot seriously join "cheaper", "more profitable" with "and", pretending that those are almost-synonyms, or are two faces of the same thing. In real business, getting things for cheap does not necessarily mean that you boost your profits. You usually pay for the cheapness somehow, if not at least in short term profits being reduced by spending on boosting productivity etc. Public corporations have a tendency to trade short term gains for long term demise, too.
Using the word "profitable" with regards to a government agency is pretty silly. An agency like DHS spends money. They don't generate any profits, because they don't bring any real money in. They get some fees and fines as income, but that's not even a drop in the bucket. If DHS were to be run as a profitable business, the true costs of their existence would be felt by every traveller, and there'd be public outrage. You'd be paying hundreds of dollars in fees per every leg of your air travel.
I don't see immediate use for the hypercube, but the individual 1, 2 and 4 core chips are phenomenal for implementing realtime ethernet devices, such as IEEE-1588 switches, realtime industrial ethernet protocols, etc. It's not hard to make a very low latency timestamping switch using one of these. The hardware assisted serialization, deserialization, and time-triggered sampling and update of ports lets you be quite creative because it decouples timing of the I/O with timing of the software. There are many applications where simple MCUs like PICs, or even Parallax's Propeller, are used for software-implements-hardware applications, but those ultimately need cycle counting and you are forced to use assembly. XMOS's XS-1 architecture decouples your software from this, and quite a lot of realtime code can be written in a high level language like C or their quite lovely XC. The latter is a safe variant of C expanded to support transputer communications and hardware-assisted ports. About the only limitation at the moment is the 64kb memory for all code and data, in all threads. Since many realtime applications usually imply little to no buffering, this hasn't been a problem for me, but it needs to be kept in mind. If one wants to have a somewhat slower but larger-memory application code running at a couple MIPS, it's certainly possible to emulate other architectures. ARM Thumb and Zylin Core can be made to work quite reasonably. There's lots of tools that generate code for Thumb, and there's a Zylin gcc port.
Alive and well as XMOS products. I love those chips.
No thrusters there. Gyros are the biggest concern it seems, they seem to last well under 10 years it seems. The panels were replaced twice, but those replacements were not due to radiation damage but due to poor mechanical performance and due to undersizing of original panels' electrical output. The first replacement panels were stiffer and would vibrate less when going from sunlight to shade and back. The second replacement panels, of Iridum vintage, were smaller and provided more power, reducing drag and vibration, and providing enough power to run any combination of instruments needed at once.
You underestimate them. They were the first private entity ever to launch a spacecraft into orbit and later retrieve it. First as in first in the world. They pulled off something that only governments could do before them. They did it for slightly more that it cost to build the useless Orion service tower.
The gyros have limited lifetime, and their failure is not some random out-of-the-blue occurrence. They will all eventually fail, well before the entire satellite will be dead.
Even with design for on-orbit repair, they could have launched 2 or 3 Hubbles for the price of one repair mission. If it was to be a throwaway design, it'd probably be more Hubbles per Shuttle launch, but so what.
I wonder what will happen to the final carrier plane. The other one was retired for parts and whatnot, per wikipedia. It probably had not very many cycles nor hours while used by NASA, although they didn't exactly buy it new either.
Space Shuttle ended up being everything to everybody, and when that happens you usually get mediocre performance. Many of its missions made no financial sense. For the cost of the Hubble repair missions they could have launched 2 or 3 more up there.
Ekhm, ekhm, SpaceX would disagree with that.
I agree wholeheartedly. Adjusting e-brakes can be done from the inside of the car in many modern cars, so there's no excuse for not having it adjusted properly. I think that at least Volvo sedans and wagons made in the last decade are all like that.
At highway speeds you don't need power steering :)
Button saying P? Emergency? What? Are we on the same planet?
The P setting on the automatic transmission applies a mechanical lock to the driveshaft. Said lock is spring-loaded and is supposed to slip on its ratchet if you happen to engage P while driving. It should normally catch and jerk your car to a stop only when you're going quite slowly (a couple km/h tops). So using the P setting to slow down the car will simply not work. It's designed to hold the car steady when parked, that's all there's to it.
If you have an automatic transmission, you'll use the hydraulic brakes normally, if those fail you can do engine braking coupled with use of emergency brake. If the car is front-wheel driven, you may get by with setting your automatic transmission into reverse at speeds of perhaps 10-25km/h, but you'd better test it under the assumption that it may be a destructive test. You've been warned :) Turning on the reverse applies a large bias to the torque converter, and you can easily lock the wheels if you're not careful with choosing your engage speed. This trick has saved my bacon once, but I'll be glad if I won't ever have to repeat it.
I have. On those the emergency brake doubles as a parking brake :) If it were a parking brake only -- designed to hold your car but not to decelerate it -- you'd really need some other system in case your hydraulic brakes have failed. A parking brake has quite a precise meaning in mechanical engineering. If you have a motor that's part of a big machine and you use its shaft lock brake (parking brake) to stop the machine (even if just to dissipate its stored kinetic energy), you may end up with a fire, and you'll likely need to service the brake to make sure it survived the maltreatment.
That's insane, for a couple of reasons. I don't think that it's even possible to take this cable out in most cars yearly even to look at it up close, without damaging various clips in the process. The cable has to be designed to accept lubrication, too -- you'd need to be able to remove the cable from the liner, or have proper grease fittings to push grease between the liner and the cable. You may have some historical car where the cable is serviceable like you claim, but it won't be the case on any modern car -- the e-brake system is simply not designed to allow such periodic lubrication. Design for serviceability plays a big role here.
It's not a parking brake, never was. It's an emergency brake. I bet most people in the U.S. never bother setting it when the car is parked, heck, many of them I'm sure wouldn't know where it is or how to use it in an emergency. There's a "P" setting on the shifter, that's good enough :/
OK, so DRI is of historical relevance at this point. Good to know.
Any parametric CAD system. Alibre Design would be one example (it is good and cheap, although, sadly, it doesn't run on OpenGL). I have some assemblies that consist of a couple thousand parts. Those parts aren't washers either, even though a washer doesn't exactly have the most trivial geometry. I've been trying to get it to run on wine for the a bit a year or two ago, and I eventually coaxed it to get as far as trying to display some geometry, so I could see how many calls into wine's directx implementation it'd do, and how much data it'd try to push. It was a couple hundred megabytes over a couple tens of thousands of calls.
Never mind that remote screens don't provide any DRI, so if you're using Mesa it probably won't be accelerated even if you have a high-end 3D card on the display. I'd like to be wrong on that one, but I'd think that Mesa needs DRI to use 3D hardware.
+1. I should have phrased it your way. You're entirely correct.
A visa is a document that entitles you to cross the border, nothing more, nothing less. It doesn't need much to do with what's your immigration status once you're in the country.
You can own and operate a business in the U.S. even without a visa -- obviously, because a visa is to cross the border and that's it. You can also own and operate such a business without having any immigration status. Heck, you can even without ever having to set foot in the U.S. None of it is illegal. Now, being employed by or rendering services for said U.S. business while also being on the U.S. soil, that's what requires appropriate status with DHS (fka INS).
What I mean by "otherwise known as VNC" is that it is local, and you're transferring bitmaps to the display. It doesn't then matter how the rendering is done (GPU, CPU, black magic, or otherwise).
Good question! No, they'd probably not pay for themselves, at least not due to their broadcast side of operations (vs. web-based). Their days are counted anyway as many young people don't care much about TV, and presumably they won't care any more as they get older. Their clientele is probably 30+ with peak, I'd guess, around 45-50 maybe. I can't imagine too many 20 year olds watching HSM.
Having had access to MFM and having looked about 8 years ago at a then-state-of-the-art hard drive I can tell you that there is no inter-track spacing with anything resembling data in it, unless that particular drive was somehow a special case. It was a rather normal laptop hard drive. Have a look at the relevant wikipedia page. There is effectively noise between the tracks of the old 3.2gb drive, but there's nothing between the tracks of the 30gb drive. A contemporary hard drive has very, very few domains that don't carry data.
3D local to the application is otherwise known as VNC. Render however and whatever, then ship the bitmap to the screen. You don't need any of X infrastructure for that. Even if you ignore the overhead of shipping the bitmap, there's still the overhead of getting the stuff rendered by the local GPU from its memory to main RAM. Such overhead is not present when the GPU renders directly to the framebuffer.
3D local to the display requires that the display and the application (X server and client) are on the same host. Otherwise the OpenGL calls are routed through a remote procedure call system. This would be fine if not for the fact that the OpenGL API horribly suffers from network latency if it's being executed using RPC. It was never designed to be used that way. Never mind that in dense datasets (say complex CAD assemblies), the geometry may well be orders of magnitude larger than the rendered framebuffer, it then makes no sense to do remote rendering on the X screen; doing it locally and shipping the resulting bitmap will take less network bandwidth.
You don't get how it works. The HSN pays the cable companies to be distributed! They are profitable, they have money! They are perhaps the poster child for how it should be done.