I know that Apple could do better, but nobody serious uses whatever is bundled with OS X when it comes to gnuland. Macports is where it's at, and the first thing you do after installing macports is sudo port followed by selfupdate and install coreutils. Then close & reopen the terminal tab, and you're up and running.
- OS X's terminal is perfectly usable. Default shortcuts are funky, but you'll get used to them. - macports is what you should be using. I like it more than the RPM I've been using since RedHat 2 (not RHEL 2, mind you). - very good in macports, OS X comes with some older python version preinstalled, though - Cmd-Tab, Cmd-C, Cmd-V, Cmd-X all work:) - bettersnaptool handles all that, but of course you can arrange your windows whatever way you wish - minor (n.n.x) version updates don't do that, major version updates (n.x) keep your installed packages usually working, but if you wish to do any package changes (updates etc.) it's best to reinstall macports, but it's very easy to do
I don't think it'll take you longer than 2 days to get used to it, as long as you read the basic keyboard shortcuts, OS X user guide, the user guide for the hardware you'll be using (e.g. iMac essentials, and google for stuff you don't know.
One more thing: to use the compiler, you need to install xcode, then from terminal run sudo gcc to accept the license. From that point on the command-line build environment is usable and you can then install macports, build your own code, etc.
Heck, when you watch media from an optical drive through OS X's DVD player or iTunes, it'll read-ahead several minutes worth of material and turn off the drive for that time. That also saves battery, and watching DVDs is quieter that way, too.
What in the f*** allows you to render full motion video at screen resolution more efficiently than you can render a few static lines of text?
Video decoding is hardware assisted and it's power-optimized to hell and back. Javascript engines can't really compete. Modern websites are, unfortunately, power hungry. It's a combination of absolutely abhorrent APIs offered by the browsers, and the cluelessness of front-end developers. Unfortunately, browser APIs exposed via javascript seem to suffer from the same lack of direction, cohesion and foresight in API design as plagues PHP.
Jet engines generally speaking tend to push stuff through them, fast fast fast. An exploding LiPo battery will linger in the engine for a very short time. A RR Trent, if perhaps an extreme example, at cruise pushes ~1.5tons of air through it per second, with 90% going through the bypass, and 10% going through the gas turbine. No matter which way the battery will go, it'll be exposed to a monumental quantity of air all eager to go into thermal equilibrium with it. As long as it doesn't mechanically damage things, I doubt that there'll be any thermal damage to speak of. The flow rates are way too high for that.
But let's not forget that the batteries are quite soft, mechanically speaking. They are more like thin plates of warm (and thus soft) lead than small plates of duraluminum. I don't know how they compare to a chicken, though.
It's harder, because not only the linear velocity must be zero, but angular velocities too, and the orientation in two axes out of three must be correct too. It's actually a fairly hard optimal control problem, and they hired the guy who came up with the math to facilitate that. What they are doing is ground-breaking not only in terms of reusability, but also in terms of engineering challenges, even at the level of basic science of control theory.
It was even better: both the Dragon and the 1st stage survived the breakup of the 2nd stage. That was a sight to behold. If it wasn't for the flight termination system, the 1st stage and Dragon could have been recovered intact. If the CRS-8 kind of S2 failure happened today, and the flight rules were such that neither the range nor the automated termination system would have blown up what's left, we would have had a Dragon and S1 recovery. That's pretty amazing capability if you ask me. Sure other things could always go wrong, but I think it's quite reassuring that we have now experience with a S2 failure that leaves S1 and the payload intact!
So, when you get to your car to drive to work in the morning, you load up every last pound of unused capacity with trash and dump it at the dumpster behind your office? If you don't, you have an operational problem at the outset. You should have bought a much smaller car, and kept your weight tightly controlled.
Consumables for the whole thing are around $200k-$250k. By "whole thing" I mean the F9+Dragon stack, which consumes LOX, kerosene, helium, nitrogen, hydraulic fluid, Draco hypergolics, and TEA-TEB for Merlin start-ups.
Conversely, there's plenty of mental midgets who won't listen to any sort of reason, so you have no recourse but stick your fingers into your ears when you're near them. Elsewhere, we call it hearing protection, and I'll be damned if it doesn't work wonderfully.
Well, I have two much thinner 2010 Macbook Pros with some corner dings with asphalt embedded in their unibody to show that the same applies to more modern, thinner hardware, too. I had a few EliteBooks around the office, I'd take even an '09 MBP over that.
They never seem to work properly when the software that uses the serial connection is written by idiots and/or the protocol is designed by idiots. I know that this reeks of no true scotsman, but I've got thousands of serial-over-USB devices that work just fine. There's an absurd number of Windows serial code that's not written in proper asynchronous manner, with multiple levels of timeouts given as explicit state machine parameters vs. one ad-hoc value that nobody bothered updating in a decade. Same goes for the code that goes into the microcontrollers that run on the devices. There is a good reason why protocols like X.25/Q.931 shouldn't be looked down upon: you have a free, patent-unencumbered protocol with a *free* test suite, with lots and lots of field experience to vouch for the soundness of the design. Yet people still design their own abominations:( I'm not saying "just use X.25", I'm saying: explore what's out there and pick up a protocol that handles all the corner cases, and ensure you understand what's going on.
It's kinda funny how everyone in the PC world bitched about Apple's products being overdesigned etc., and now every modern notebook looks more and more like an Apple product. If only the stupid PC manufacturers would stop putting the damn intake vents on the bottom of the damn things, we'd be golden. Good luck using something with bottom intakes on your lap if you're wearing anything that'll block them. Most women have that problem.
For that kind of a price tag they could assign an official quarter to every TSA employee out there, and have them toss a freakin' coin. How stupid can the gov't get?
The printer on a secure network has no connection to the public internet. There is no routing between the secure and insecure networks. So, the printer can't use the network it's plugged to by wire. It would need to leak data via a cellular modem. Easy to do. Not every secure location jams the good old cell networks.
Frankly said, is there anything that's reasonably hot/current in the content world that isn't for purchase on U.S. iTunes? These days, for current releases, iTunes is way less hassle than bittorrent...
Very small portion of the day? Charging is typically done at night, when the demand for electricity is the lowest. It's actually a win-win for electric utilities, since they get paid for what amounts to unused capacity sitting idle and costing them money.
Frankly said, if you're in the U.S. and want USB cables, you buy them from DigiKey, Newark, Mouser, or Allied Electronics. That's it. There's literally no other vendor I'd trust. As far as I'm concerned, these are the only legitimate sources of compliant cables at competitive prices.
LTPoE++ gives you 90W, so power isn't a problem, and it works over 1Gb/s no problem. I don't know if there's any IEEE standard for 90W POE, though. LTPoE++ is good enough for me - I design it in and it works great.
A polyfuse is way, way too slow to protect semiconductor voltage regulators. If you apply -20V to a USB-C port's VBUS, no polyfuse will protect you. You'll need active semiconductor protection, like an ideal diode controlled by a current limiter.
Well, it was a Chromebook. What did you expect. It's wouldn't be cheap if they keept adding $0.30 worth of fuses here, some other protection there. It's a barebones piece of hardware that will play nice with compliant peripeharals, and that's about it.
Slashdot Mirror
I know that Apple could do better, but nobody serious uses whatever is bundled with OS X when it comes to gnuland. Macports is where it's at, and the first thing you do after installing macports is sudo port followed by selfupdate and install coreutils. Then close & reopen the terminal tab, and you're up and running.
- OS X's terminal is perfectly usable. Default shortcuts are funky, but you'll get used to them. :)
- macports is what you should be using. I like it more than the RPM I've been using since RedHat 2 (not RHEL 2, mind you).
- very good in macports, OS X comes with some older python version preinstalled, though
- Cmd-Tab, Cmd-C, Cmd-V, Cmd-X all work
- bettersnaptool handles all that, but of course you can arrange your windows whatever way you wish
- minor (n.n.x) version updates don't do that, major version updates (n.x) keep your installed packages usually working, but if you wish to do any package changes (updates etc.) it's best to reinstall macports, but it's very easy to do
I don't think it'll take you longer than 2 days to get used to it, as long as you read the basic keyboard shortcuts, OS X user guide, the user guide for the hardware you'll be using (e.g. iMac essentials, and google for stuff you don't know.
One more thing: to use the compiler, you need to install xcode, then from terminal run sudo gcc to accept the license. From that point on the command-line build environment is usable and you can then install macports, build your own code, etc.
Heck, when you watch media from an optical drive through OS X's DVD player or iTunes, it'll read-ahead several minutes worth of material and turn off the drive for that time. That also saves battery, and watching DVDs is quieter that way, too.
What in the f*** allows you to render full motion video at screen resolution more efficiently than you can render a few static lines of text?
Video decoding is hardware assisted and it's power-optimized to hell and back. Javascript engines can't really compete. Modern websites are, unfortunately, power hungry. It's a combination of absolutely abhorrent APIs offered by the browsers, and the cluelessness of front-end developers. Unfortunately, browser APIs exposed via javascript seem to suffer from the same lack of direction, cohesion and foresight in API design as plagues PHP.
Jet engines generally speaking tend to push stuff through them, fast fast fast. An exploding LiPo battery will linger in the engine for a very short time. A RR Trent, if perhaps an extreme example, at cruise pushes ~1.5tons of air through it per second, with 90% going through the bypass, and 10% going through the gas turbine. No matter which way the battery will go, it'll be exposed to a monumental quantity of air all eager to go into thermal equilibrium with it. As long as it doesn't mechanically damage things, I doubt that there'll be any thermal damage to speak of. The flow rates are way too high for that.
Exactly. Focusing on the battery is silly, all the while the motor are like steel nuts, damage-potential-wise.
But let's not forget that the batteries are quite soft, mechanically speaking. They are more like thin plates of warm (and thus soft) lead than small plates of duraluminum. I don't know how they compare to a chicken, though.
It's harder, because not only the linear velocity must be zero, but angular velocities too, and the orientation in two axes out of three must be correct too. It's actually a fairly hard optimal control problem, and they hired the guy who came up with the math to facilitate that. What they are doing is ground-breaking not only in terms of reusability, but also in terms of engineering challenges, even at the level of basic science of control theory.
It was even better: both the Dragon and the 1st stage survived the breakup of the 2nd stage. That was a sight to behold. If it wasn't for the flight termination system, the 1st stage and Dragon could have been recovered intact. If the CRS-8 kind of S2 failure happened today, and the flight rules were such that neither the range nor the automated termination system would have blown up what's left, we would have had a Dragon and S1 recovery. That's pretty amazing capability if you ask me. Sure other things could always go wrong, but I think it's quite reassuring that we have now experience with a S2 failure that leaves S1 and the payload intact!
So, when you get to your car to drive to work in the morning, you load up every last pound of unused capacity with trash and dump it at the dumpster behind your office? If you don't, you have an operational problem at the outset. You should have bought a much smaller car, and kept your weight tightly controlled.
Consumables for the whole thing are around $200k-$250k. By "whole thing" I mean the F9+Dragon stack, which consumes LOX, kerosene, helium, nitrogen, hydraulic fluid, Draco hypergolics, and TEA-TEB for Merlin start-ups.
Conversely, there's plenty of mental midgets who won't listen to any sort of reason, so you have no recourse but stick your fingers into your ears when you're near them. Elsewhere, we call it hearing protection, and I'll be damned if it doesn't work wonderfully.
Well, I have two much thinner 2010 Macbook Pros with some corner dings with asphalt embedded in their unibody to show that the same applies to more modern, thinner hardware, too. I had a few EliteBooks around the office, I'd take even an '09 MBP over that.
They never seem to work properly when the software that uses the serial connection is written by idiots and/or the protocol is designed by idiots. I know that this reeks of no true scotsman, but I've got thousands of serial-over-USB devices that work just fine. There's an absurd number of Windows serial code that's not written in proper asynchronous manner, with multiple levels of timeouts given as explicit state machine parameters vs. one ad-hoc value that nobody bothered updating in a decade. Same goes for the code that goes into the microcontrollers that run on the devices. There is a good reason why protocols like X.25/Q.931 shouldn't be looked down upon: you have a free, patent-unencumbered protocol with a *free* test suite, with lots and lots of field experience to vouch for the soundness of the design. Yet people still design their own abominations :( I'm not saying "just use X.25", I'm saying: explore what's out there and pick up a protocol that handles all the corner cases, and ensure you understand what's going on.
It's kinda funny how everyone in the PC world bitched about Apple's products being overdesigned etc., and now every modern notebook looks more and more like an Apple product. If only the stupid PC manufacturers would stop putting the damn intake vents on the bottom of the damn things, we'd be golden. Good luck using something with bottom intakes on your lap if you're wearing anything that'll block them. Most women have that problem.
Moreover, who the heck cares how thin a laptop is? Past a certain point, any "improvement" in that respect is pointless.
For that kind of a price tag they could assign an official quarter to every TSA employee out there, and have them toss a freakin' coin. How stupid can the gov't get?
The printer on a secure network has no connection to the public internet. There is no routing between the secure and insecure networks. So, the printer can't use the network it's plugged to by wire. It would need to leak data via a cellular modem. Easy to do. Not every secure location jams the good old cell networks.
Frankly said, is there anything that's reasonably hot/current in the content world that isn't for purchase on U.S. iTunes? These days, for current releases, iTunes is way less hassle than bittorrent...
Very small portion of the day? Charging is typically done at night, when the demand for electricity is the lowest. It's actually a win-win for electric utilities, since they get paid for what amounts to unused capacity sitting idle and costing them money.
Frankly said, if you're in the U.S. and want USB cables, you buy them from DigiKey, Newark, Mouser, or Allied Electronics. That's it. There's literally no other vendor I'd trust. As far as I'm concerned, these are the only legitimate sources of compliant cables at competitive prices.
LTPoE++ gives you 90W, so power isn't a problem, and it works over 1Gb/s no problem. I don't know if there's any IEEE standard for 90W POE, though. LTPoE++ is good enough for me - I design it in and it works great.
A polyfuse is way, way too slow to protect semiconductor voltage regulators. If you apply -20V to a USB-C port's VBUS, no polyfuse will protect you. You'll need active semiconductor protection, like an ideal diode controlled by a current limiter.
Well, it was a Chromebook. What did you expect. It's wouldn't be cheap if they keept adding $0.30 worth of fuses here, some other protection there. It's a barebones piece of hardware that will play nice with compliant peripeharals, and that's about it.
Trying to use a gun while surrounded by mobsters would be suicide.
You assume they don't care about their life. They usually do, and gun is a bit of an equalizer.