Because the rocket is almost out of fuel, even burning only one engine at minimum throttle, the thrust to weight ratio is more than one (ie, the rocket would fly, not land). So, they can't hover, they have to hit the ship and shut the engine off at the exact moment that the velocity is zero (or very close to it). So, to help with that problem, they come in at an angle which helps consume at least some of the thrust in a direction that isn't upward.
The second reason is, as you say, to protect the landing platform. If they run out of fuel (or the engine fails or....), the stage just drops into the ocean rather than crashing into the barge at a very high speed. That said, based on their last several failed landing attempts, that barge can take quite a hit and stay in one piece....
Yeah, I think their math is off as well. My wife and I have the camera that they seem to have used (a Canon 70D - you can see it in some of their "Making Of" shots) and it shoots full-res RAW files in the 25MB to 35MB range. Even if you turn on RAW+JPEG mode, that's at most ~40MB/image. So I'm not clear on how they ended up with that much data unless it's, like, 20 shots per location and 70,000 locations? But then why say 70,000 images?
I have a choice of which computer and handset I choose to buy and (on the computer) what OS to run. I have two choices in ISP's, or I can move where I *might* have two different choices in ISP's (or not). Moving is a pretty high bar to clear. Buying another handset or changing OS's (or even buying a second handset or computer) because whatever application I want isn't available on the platform I have is a much lower bar.
The problem is that we have chosen to not allow everyone and their brother to dig up the street to lay new cable or string new cable on overhead wires. There are good reasons for that. That, however, means that the so called "last mile" delivery, at least to residential areas, is always going to be a place where competition is artificially limited. So, at that point, you either take the cable-TV route and just let the monopoly abuse its customer base with no innovation for *years* or you need some government regulation to get more competition. Neutrality is one form of that regulation. Personally, I think that without it, the Internet as we know it will cease to exist and turn, instead, into content channels that are available like cable-TV channels on whatever ISP you happen to be attached to. That will severely restrict new websites from being created. Maybe that view is too pessimistic. Another option (or an additional option on top of neutrality) is to have the public "own" (or at least have a strong interest in the operation of) the last-mile network, kind of like the public owns the roads, and force the actual owner of the cable to allow multiple ISPs to exist on the cable (that could also take the form of prohibiting a single company from operating both a last-mile infrastructure and offering public Internet access, or several other similar forms, or it could just mandate that the lines must be leased to anyone who can pay to play).
I'd love to hear another set of options that can be plausibly implemented that would encourage competition in content creation and content delivery that doesn't a) require government regulation (remember, prohibiting exclusive contracts for last-mile service is, itself, a government regulation against an otherwise legal contract) and b) doesn't involve an unwieldy tangle of wires above and/or below every street.
Assuming you weren't kidding.... The original MacBook (not the MacBook Pro, which has always been silver) and several follow on models were available in both white and black. See the Wikipedia picture: http://en.wikipedia.org/wiki/M...
One of the biggest reasons is that, in the location this is happening, parachutes means "lands in the ocean" which implies that your rocket is going to get bathed in salt water, probably engines first. I'm sure you could design some sort of a deployable cover to cover the engines (although they're have to be vented of fuel and cooled first) that would prevent salt water from entering, but I doubt that would be less complex than this scheme and it would almost certainly be heavier.
Finally, remember that one of Elon Musk's long term goals is to land on Mars (whether he will actually achieve that, I have no idea, but he's heading in the right direction) and for that, parachutes won't work. So, this whole thing is really an R&D program. Even if they "only" recover 50% of the spent stages, that's a lot of "cost of goods sold" to cut out.....
I didn't say never look at them, I said never remove the extra photos from your Lightroom catalog, find the files on disk, delete them, and hope you didn't accidentally delete IMG_8192.JPG instead of IMG_8191.JPG. And yes, it *is* easier to just store them than to do that. If hard drive sizes stop increasing, or the photo cataloging software gets better, that may change. In the mean time, the disk space is cheaper and easier than the time to deal with it.
It really depends on why you're taking the pictures. If you are just trying to have the memory, then yeah, you don't need 15 pictures in sports mode. But if you're trying to do something artistic then that's how you do it. And while you *can* sift through and delete all the ones that aren't the best, it's a lot easier to *not* have to do that and just store 'em. How much is your time worth vs. $250 for an 8 TB hard drive that can store, probably, all the pictures we'll take in the next 15 years.
Yeah, but a better camera will be more than that. My wife and I took over 7000 pictures on our honeymoon (which lasted about a month) with a Canon camera. That's about 7MB/picture (seems to go up to about 12 for JPEG). If we'd taken them in RAW (which, arguably, we should have since some of the shots would be nice to reedit or do lens correction on) it would've been around 25 to 30MB/image with our camera. If you use sports mode (taking 10 or 15 shots every time you push the button), I could easily see hitting 100GB/month. All depends on whether this guy's wife is as obsessive about her "recreation" as my wife and I are....
I design audio for theater. I have a 3TB archive of my designs and it grows about 300GB per year (musicals, where I do recording, take about 100GB per show). My wife likes taking pictures and she generates a few gigabytes per month of pictures. Many people keep movies. My parents have an archive of their favorite (broadcast) TV shows that they recorded with EyeTV. You're right that it's extremely likely that nobody will care about most of this stuff when we die. But we're still alive. What's so hard to understand about that?
Yeah, I could spend hours paring down my audio collection. I could delete the musical recordings, eliminate duplicates, and throw away shows I'm likely to never revisit. My wife could delete most of her pictures (ones that were out of focus, test shots, ones that she doesn't like for some reason). My parents could buy DVDs (which are simply a less convenient form of storage). But why would any of us do this? I occasionally get asked to remix songs and I reuse sound effects from shows sometimes. My wife goes back and looks at shots or may change her mind about what she wants to keep.
When you can fit 8TB on something the size of a medium book, why wouldn't you keep stuff you might use again?
THIS (* see below) dizzying pile of config files with nondescript names. And that doesn't even include the set of names that are magically generated either implicitly and from other files. For reference,/etc/init.d has less than half this many files. Furthermore, to know what actually is going to boot, I cd into a directory and type "ls". Can anyone tell me which of these is actually going to execute when my machine boots?
To answer a non-rehetorical question: Can any of the systemd lovers (or haters, I'm not picky) tell me how the heck I move/var to a different filesystem without editing every single file in that directory below? Just putting the mount point in/etc/fstab doesn't work because stuff that depends on/var executes before/var gets mounted. I added a unit file to mount/var and gave it a "before" dependency on dbus (which is the first thing that seems to break), but it starts dbus while it's doing the fsck on/var anyway.
(*) The list was going to go here. But it's so long Slashdot won't let me post it. There are 255 unit files in/usr/lib/systemd/system. They have fun names like "systemd-tmpfiles-setup-dev.service".
Yeah, I was surprised as well. It's normal to relay in the US as well. I switched to Comcast earlier this year from CenturyLink. With CenturyLink, I was relaying through their SMTP server. Comcast doesn't allow that (at least on Business Class accounts).
You can't use that on a Comcast Business account (or at least my Comcast Business account couldn't). After 4 phone calls, they finally confirmed that their mail server won't send mail for anyone else's domain. Ie, if you own example.com, Comcast's server won't relay mail for foo@example.com only for foo@comcast.net.
Now.... My information is about 7 months old so maybe they changed this without telling anyone? If your information is newer I should probably revisit my mail configuration.
Meantime, I just tried from my domain (email server sends directly from a Comcast Business IP) and had no problems sending to Yahoo Mail so they aren't blocking *ALL* Comcast Business IP's. I also have (hopefully) correct reverse DNS on my email server and SPF records in my DNS.
(Now if Stripe is applying their rules differently for different people, that *is* a problem. If, for instance, they'd happily process payments for a gun store/manufacturer owned by a Democrat but not a Libertarian or a Republican, *that* I'd have a problem with even though I tend to be a Democrat).
There is actually a huge difference in the argument you are making. There's a difference between choosing *who* you do business with (or employ) and *what kind* of business you are willing to be in. If you're a gun store and you refuse to sell someone a gun because they're gay, that should be illegal (whether it actually *is* illegal is still being debated). If you're, say, a department store and you don't wish to be in the business of selling guns, you should have a right not to be. I think this case is pretty clear cut that the payment processor has a right not to be in the business of processing payments for guns.
The RSO's are actually not even from NASA. They are from the US Air Force 45th Space Wing (I knew that was true at KSC and Wikipedia confirms it's the same group that does Wallops).
...except that I'm talking about *corrupt* logs, not *correct* logs. I maintain that in the face of corruption, a human parsing an ASCII log will beat a computer parsing a non-ASCII log any day.
NO! I don't see why this is so hard to get. ASCII is a one to one mapping with human language. "Binary" logs (i.e., logs with an encoding other than 7 bit ASCII since we're going to be SUPER pedantic here apparently) are not. Especially if they are compressed or the encoding is complicated in other ways. When stuff gets corrupted the best filter for that corruption is the human brain. But that assumes the brain can parse the encoding. I can parse the English alphabet (and the Spanish one on a good day).
What do you think will happen if I want journald to parse, say, "ap#@1e2: p@#$ission denied"? Is that going to correctly end up with "apache2: permission denied"? I doubt it. But I probably will. Especially if I already know that I'm having issues with Apache. And if you don't like that example, I'm sure I can come up with a lot more.
The implication isn't that SysV init is problem free. The implication is that SysV init is *debuggable*. A 900+ edge directed graph that controls my system startup is *not* debuggable. Especially when some of the nodes and edges are created implicitly (if you're wondering what I'm talking about, ask systemd to produce a dot formatted graph of the startup process. Just don't ask it to do that in a chroot environment because it won't, but that's a different rant). Oh - and it seems to ignore some of the dependencies (edges in the graph) but not others.
Because 85% (a number I just made up) of the point of log files is to *figure stuff out when things go wrong*. When things go wrong, binary logs sometimes end up corrupted (witness all of my journald logs from last week - no, I don't know why yet). I am a *LOT* better at sifting through a corrupt text log than a computer is at sifting through a corrupt binary log. Journald just says "your log is corrupt" and I lose. I've noticed that even "strings" doesn't get text out of a (non-corrupt) journald log (at least not all the logs, maybe some of them?). Now please give me *one* advantage of binary logs over properly formatted text logs. The reason syslog is so hard to parse is that it splits lines stupidly. There's no (modern) reason for that. So when I say "properly formatted", I definitely don't mean syslog as is. Think syslog with lines of any length.
Err... Western Design Center sells them. Mouser claims to have a few hundred 65c02's in stock in a variety of form factors (PLC-44, QFP-44, and DIP-40) as well as 65816's. The 65816 is compatible enough that if you clocked it at 1MHz, you'd almost certainly end up with a 100% compatible design (though if I remember back to my Apple IIgs days correctly, there are a few minor incompatibilities, even when running the 65816 in 8 bit mode).
It may only do one thing, but it most *certainly* does not do it well. I've yet to have a system with an NFS mounted root filesystem correctly shut down under systemd.
Yeah: Inability to debug what is wrong with the init system when you aren't doing exactly the use case that "normal" people use. I have a number of problems with it, but here's one: I've been trying for the last two weeks to end up in a place where my root filesystem was served up by NFS and/var was on a local partition. I had that working under OpenSuSE and need to switch (for unrelated reasons) to Fedora. First, my filesystem didn't get mounted read/write. Easy fix, once you know what's wrong except that journald swallowed all the output (even though I turned on journal+console) and I had no log because of the read only filesystem. The only indication of what was ewrong was systemd saying journald had timed out. On a hunch (after seeing posts on the Arch Linux boards) I added "rw" to the kernel command line and finally got a login prompt. Now, I can't get the/var filesystem to mount before dbus starts because udev depends on dbus and the mount is a systemd special that depends on the device being present which it is, but it requires udev and dbus just to check to be sure. I've also got some weird issue with dependencies not being satisfied so the console getty never starts (on a serial console - the correct unit file seems to be there), but I'm ignoring that since I have network access. Oh, and the system won't shut down cleanly because it shuts down the network before unmounting the root filesystem which is mounted over NFS. But again, I don't even care about that anymore - I just hard reset it with the BMC. I'm sure you'll tell me that I'm a moron and have the thing horrible misconfigured. I *do* have it horribly misconfigured. What I'd like to know is how to *fix* it and systemd is getting in the way of that.
In SysV init, I would've seen stuff whining about permission denied errors on the console (instead of all the output being eaten, despite turning on debug mode and journal+console mode) and realized I probably didn't have the filesystem mounted right. For the/var stuff, I'd just put it in/etc/fstab and be done. On the off chance that that was not early enough in boot, I'd add a shell script (or hack it into the earliest script) to do the mount. With systemd, I've tried creating unit files several different ways. Telling them they have to run before the stuff that is breaking. No dice. I have no idea why. I thought "ok, I'll just test-run this in a chroot environment". Nope. Systemd won't run there, even to just tell you what it *would* do. In the end, I've wasted weeks on this, learned little about systemd (despite trying - it's the future whether I like it or not. And I don't), and if I ever get it working, systemd won't have gotten me *anything* that I didn't have before. I'd *vastly* prefer an architecture where normal/etc/init handled
I don't think that the former poster is complaining that the source trees happen to be managed the same way. He's complaining that dependencies are being created between different pieces of software that don't need it. If systemd were set up to where there was a standard/sbin/init and SysV (or similar) init scripts and in a desktop Linux, there was only one script: start systemd, I'd be happy. I suspect most other sysadmin/developer people who hate systemd would be happy. I don't care if it exists, and I don't even care if it exists by default. What I *want* is to easily get rid of it when it's not appropriate for the task I am trying to accomplish and there isn't currently a way of doing that because systemd, journald, dbus, and udev are all tied into one big knot.
The ability to quickly design and produce an ASIC is hardly new or innovative here. ASICs are one of the few pieces of computing that you can get done faster if you just throw more people at the problem. Plus, I have a strong suspicion that most Bitcoin mining ASICs are Gate Array ASICs (http://www.fujitsu.com/emea/services/microelectronics/asic/asic/techprod/gatearray/) which, if my understanding of them is correct, use a bunch of standard layers and interconnect them with a few custom layers. That reduces the number of masks needed as well as reducing NRE charges and minimum quantities. Essentially, it's an FPGA where the interconnection is hard wired.
Now as to your prediction that multipurpose CPUs may go away (or become a small piece of a computer), that may turn out to be true. Special purpose ASICs to solve specific problems in high performance computing have been proposed many times, though to my knowledge, not actually built. At some point, though, someone will build one. Especially as the feature sizes stop getting smaller, going to custom logic to solve problems will be the next logical way to speed things up. However, the current generation of Bitcoin mining isn't going to be contributing anything to it.
Apparently (and this is my understanding with no inside knowledge, so take it with a grain of salt), they don't have live video telemetry from the stage during decent. They have a variety of engineering data, but to get decent video, they need to get the stage back. Given that it blew up, I'm guessing that's unlikely. Last time, they had some spotty video relayed off a tracking aircraft, but they had to wait for the aircraft to land before anyone saw it. Maybe the same will happen here? Also, as a company, I have a suspicion that they aren't thrilled with releasing videos of their rockets exploding. While a lot of people here understand that that's likely inevitable, given how complex a task they're trying to achieve, the general public probably won't....
There are two reasons that I've seen.
Because the rocket is almost out of fuel, even burning only one engine at minimum throttle, the thrust to weight ratio is more than one (ie, the rocket would fly, not land). So, they can't hover, they have to hit the ship and shut the engine off at the exact moment that the velocity is zero (or very close to it). So, to help with that problem, they come in at an angle which helps consume at least some of the thrust in a direction that isn't upward.
The second reason is, as you say, to protect the landing platform. If they run out of fuel (or the engine fails or....), the stage just drops into the ocean rather than crashing into the barge at a very high speed. That said, based on their last several failed landing attempts, that barge can take quite a hit and stay in one piece....
Yeah, I think their math is off as well. My wife and I have the camera that they seem to have used (a Canon 70D - you can see it in some of their "Making Of" shots) and it shoots full-res RAW files in the 25MB to 35MB range. Even if you turn on RAW+JPEG mode, that's at most ~40MB/image. So I'm not clear on how they ended up with that much data unless it's, like, 20 shots per location and 70,000 locations? But then why say 70,000 images?
I have a choice of which computer and handset I choose to buy and (on the computer) what OS to run. I have two choices in ISP's, or I can move where I *might* have two different choices in ISP's (or not). Moving is a pretty high bar to clear. Buying another handset or changing OS's (or even buying a second handset or computer) because whatever application I want isn't available on the platform I have is a much lower bar.
The problem is that we have chosen to not allow everyone and their brother to dig up the street to lay new cable or string new cable on overhead wires. There are good reasons for that. That, however, means that the so called "last mile" delivery, at least to residential areas, is always going to be a place where competition is artificially limited. So, at that point, you either take the cable-TV route and just let the monopoly abuse its customer base with no innovation for *years* or you need some government regulation to get more competition. Neutrality is one form of that regulation. Personally, I think that without it, the Internet as we know it will cease to exist and turn, instead, into content channels that are available like cable-TV channels on whatever ISP you happen to be attached to. That will severely restrict new websites from being created. Maybe that view is too pessimistic. Another option (or an additional option on top of neutrality) is to have the public "own" (or at least have a strong interest in the operation of) the last-mile network, kind of like the public owns the roads, and force the actual owner of the cable to allow multiple ISPs to exist on the cable (that could also take the form of prohibiting a single company from operating both a last-mile infrastructure and offering public Internet access, or several other similar forms, or it could just mandate that the lines must be leased to anyone who can pay to play).
I'd love to hear another set of options that can be plausibly implemented that would encourage competition in content creation and content delivery that doesn't a) require government regulation (remember, prohibiting exclusive contracts for last-mile service is, itself, a government regulation against an otherwise legal contract) and b) doesn't involve an unwieldy tangle of wires above and/or below every street.
Assuming you weren't kidding.... The original MacBook (not the MacBook Pro, which has always been silver) and several follow on models were available in both white and black. See the Wikipedia picture: http://en.wikipedia.org/wiki/M...
One of the biggest reasons is that, in the location this is happening, parachutes means "lands in the ocean" which implies that your rocket is going to get bathed in salt water, probably engines first. I'm sure you could design some sort of a deployable cover to cover the engines (although they're have to be vented of fuel and cooled first) that would prevent salt water from entering, but I doubt that would be less complex than this scheme and it would almost certainly be heavier.
Finally, remember that one of Elon Musk's long term goals is to land on Mars (whether he will actually achieve that, I have no idea, but he's heading in the right direction) and for that, parachutes won't work. So, this whole thing is really an R&D program. Even if they "only" recover 50% of the spent stages, that's a lot of "cost of goods sold" to cut out.....
I didn't say never look at them, I said never remove the extra photos from your Lightroom catalog, find the files on disk, delete them, and hope you didn't accidentally delete IMG_8192.JPG instead of IMG_8191.JPG. And yes, it *is* easier to just store them than to do that. If hard drive sizes stop increasing, or the photo cataloging software gets better, that may change. In the mean time, the disk space is cheaper and easier than the time to deal with it.
It really depends on why you're taking the pictures. If you are just trying to have the memory, then yeah, you don't need 15 pictures in sports mode. But if you're trying to do something artistic then that's how you do it. And while you *can* sift through and delete all the ones that aren't the best, it's a lot easier to *not* have to do that and just store 'em. How much is your time worth vs. $250 for an 8 TB hard drive that can store, probably, all the pictures we'll take in the next 15 years.
Yeah, but a better camera will be more than that. My wife and I took over 7000 pictures on our honeymoon (which lasted about a month) with a Canon camera. That's about 7MB/picture (seems to go up to about 12 for JPEG). If we'd taken them in RAW (which, arguably, we should have since some of the shots would be nice to reedit or do lens correction on) it would've been around 25 to 30MB/image with our camera. If you use sports mode (taking 10 or 15 shots every time you push the button), I could easily see hitting 100GB/month. All depends on whether this guy's wife is as obsessive about her "recreation" as my wife and I are....
I design audio for theater. I have a 3TB archive of my designs and it grows about 300GB per year (musicals, where I do recording, take about 100GB per show). My wife likes taking pictures and she generates a few gigabytes per month of pictures. Many people keep movies. My parents have an archive of their favorite (broadcast) TV shows that they recorded with EyeTV. You're right that it's extremely likely that nobody will care about most of this stuff when we die. But we're still alive. What's so hard to understand about that?
Yeah, I could spend hours paring down my audio collection. I could delete the musical recordings, eliminate duplicates, and throw away shows I'm likely to never revisit. My wife could delete most of her pictures (ones that were out of focus, test shots, ones that she doesn't like for some reason). My parents could buy DVDs (which are simply a less convenient form of storage). But why would any of us do this? I occasionally get asked to remix songs and I reuse sound effects from shows sometimes. My wife goes back and looks at shots or may change her mind about what she wants to keep.
When you can fit 8TB on something the size of a medium book, why wouldn't you keep stuff you might use again?
THIS (* see below) dizzying pile of config files with nondescript names. And that doesn't even include the set of names that are magically generated either implicitly and from other files. For reference, /etc/init.d has less than half this many files. Furthermore, to know what actually is going to boot, I cd into a directory and type "ls". Can anyone tell me which of these is actually going to execute when my machine boots?
To answer a non-rehetorical question: Can any of the systemd lovers (or haters, I'm not picky) tell me how the heck I move /var to a different filesystem without editing every single file in that directory below? Just putting the mount point in /etc/fstab doesn't work because stuff that depends on /var executes before /var gets mounted. I added a unit file to mount /var and gave it a "before" dependency on dbus (which is the first thing that seems to break), but it starts dbus while it's doing the fsck on /var anyway.
(*) The list was going to go here. But it's so long Slashdot won't let me post it. There are 255 unit files in /usr/lib/systemd/system. They have fun names like "systemd-tmpfiles-setup-dev.service".
Yeah, I was surprised as well. It's normal to relay in the US as well. I switched to Comcast earlier this year from CenturyLink. With CenturyLink, I was relaying through their SMTP server. Comcast doesn't allow that (at least on Business Class accounts).
You can't use that on a Comcast Business account (or at least my Comcast Business account couldn't). After 4 phone calls, they finally confirmed that their mail server won't send mail for anyone else's domain. Ie, if you own example.com, Comcast's server won't relay mail for foo@example.com only for foo@comcast.net.
Now.... My information is about 7 months old so maybe they changed this without telling anyone? If your information is newer I should probably revisit my mail configuration.
Meantime, I just tried from my domain (email server sends directly from a Comcast Business IP) and had no problems sending to Yahoo Mail so they aren't blocking *ALL* Comcast Business IP's. I also have (hopefully) correct reverse DNS on my email server and SPF records in my DNS.
(Now if Stripe is applying their rules differently for different people, that *is* a problem. If, for instance, they'd happily process payments for a gun store/manufacturer owned by a Democrat but not a Libertarian or a Republican, *that* I'd have a problem with even though I tend to be a Democrat).
There is actually a huge difference in the argument you are making. There's a difference between choosing *who* you do business with (or employ) and *what kind* of business you are willing to be in. If you're a gun store and you refuse to sell someone a gun because they're gay, that should be illegal (whether it actually *is* illegal is still being debated). If you're, say, a department store and you don't wish to be in the business of selling guns, you should have a right not to be. I think this case is pretty clear cut that the payment processor has a right not to be in the business of processing payments for guns.
The incident you are thinking of is, I think, when Neil Armstrong crashed in the Lunar Module Simulator.
http://www.huffingtonpost.com/...
Apparently the story goes that he was back in his office eating lunch a few hours later like nothing happened.
The RSO's are actually not even from NASA. They are from the US Air Force 45th Space Wing (I knew that was true at KSC and Wikipedia confirms it's the same group that does Wallops).
...except that I'm talking about *corrupt* logs, not *correct* logs. I maintain that in the face of corruption, a human parsing an ASCII log will beat a computer parsing a non-ASCII log any day.
NO! I don't see why this is so hard to get. ASCII is a one to one mapping with human language. "Binary" logs (i.e., logs with an encoding other than 7 bit ASCII since we're going to be SUPER pedantic here apparently) are not. Especially if they are compressed or the encoding is complicated in other ways. When stuff gets corrupted the best filter for that corruption is the human brain. But that assumes the brain can parse the encoding. I can parse the English alphabet (and the Spanish one on a good day).
What do you think will happen if I want journald to parse, say, "ap#@1e2: p@#$ission denied"? Is that going to correctly end up with "apache2: permission denied"? I doubt it. But I probably will. Especially if I already know that I'm having issues with Apache. And if you don't like that example, I'm sure I can come up with a lot more.
The implication isn't that SysV init is problem free. The implication is that SysV init is *debuggable*. A 900+ edge directed graph that controls my system startup is *not* debuggable. Especially when some of the nodes and edges are created implicitly (if you're wondering what I'm talking about, ask systemd to produce a dot formatted graph of the startup process. Just don't ask it to do that in a chroot environment because it won't, but that's a different rant). Oh - and it seems to ignore some of the dependencies (edges in the graph) but not others.
Because 85% (a number I just made up) of the point of log files is to *figure stuff out when things go wrong*. When things go wrong, binary logs sometimes end up corrupted (witness all of my journald logs from last week - no, I don't know why yet). I am a *LOT* better at sifting through a corrupt text log than a computer is at sifting through a corrupt binary log. Journald just says "your log is corrupt" and I lose. I've noticed that even "strings" doesn't get text out of a (non-corrupt) journald log (at least not all the logs, maybe some of them?). Now please give me *one* advantage of binary logs over properly formatted text logs. The reason syslog is so hard to parse is that it splits lines stupidly. There's no (modern) reason for that. So when I say "properly formatted", I definitely don't mean syslog as is. Think syslog with lines of any length.
Err... Western Design Center sells them. Mouser claims to have a few hundred 65c02's in stock in a variety of form factors (PLC-44, QFP-44, and DIP-40) as well as 65816's. The 65816 is compatible enough that if you clocked it at 1MHz, you'd almost certainly end up with a 100% compatible design (though if I remember back to my Apple IIgs days correctly, there are a few minor incompatibilities, even when running the 65816 in 8 bit mode).
It may only do one thing, but it most *certainly* does not do it well. I've yet to have a system with an NFS mounted root filesystem correctly shut down under systemd.
Yeah: Inability to debug what is wrong with the init system when you aren't doing exactly the use case that "normal" people use. I have a number of problems with it, but here's one: /var was on a local partition. I had that working under OpenSuSE and need to switch (for unrelated reasons) to Fedora. First, my filesystem didn't get mounted read/write. Easy fix, once you know what's wrong except that journald swallowed all the output (even though I turned on journal+console) and I had no log because of the read only filesystem. The only indication of what was ewrong was systemd saying journald had timed out. On a hunch (after seeing posts on the Arch Linux boards) I added "rw" to the kernel command line and finally got a login prompt. Now, I can't get the /var filesystem to mount before dbus starts because udev depends on dbus and the mount is a systemd special that depends on the device being present which it is, but it requires udev and dbus just to check to be sure. I've also got some weird issue with dependencies not being satisfied so the console getty never starts (on a serial console - the correct unit file seems to be there), but I'm ignoring that since I have network access. Oh, and the system won't shut down cleanly because it shuts down the network before unmounting the root filesystem which is mounted over NFS. But again, I don't even care about that anymore - I just hard reset it with the BMC. I'm sure you'll tell me that I'm a moron and have the thing horrible misconfigured. I *do* have it horribly misconfigured. What I'd like to know is how to *fix* it and systemd is getting in the way of that.
I've been trying for the last two weeks to end up in a place where my root filesystem was served up by NFS and
In SysV init, I would've seen stuff whining about permission denied errors on the console (instead of all the output being eaten, despite turning on debug mode and journal+console mode) and realized I probably didn't have the filesystem mounted right. For the /var stuff, I'd just put it in /etc/fstab and be done. On the off chance that that was not early enough in boot, I'd add a shell script (or hack it into the earliest script) to do the mount. With systemd, I've tried creating unit files several different ways. Telling them they have to run before the stuff that is breaking. No dice. I have no idea why. I thought "ok, I'll just test-run this in a chroot environment". Nope. Systemd won't run there, even to just tell you what it *would* do. In the end, I've wasted weeks on this, learned little about systemd (despite trying - it's the future whether I like it or not. And I don't), and if I ever get it working, systemd won't have gotten me *anything* that I didn't have before. I'd *vastly* prefer an architecture where normal /etc/init handled
I don't think that the former poster is complaining that the source trees happen to be managed the same way. He's complaining that dependencies are being created between different pieces of software that don't need it. If systemd were set up to where there was a standard /sbin/init and SysV (or similar) init scripts and in a desktop Linux, there was only one script: start systemd, I'd be happy. I suspect most other sysadmin/developer people who hate systemd would be happy. I don't care if it exists, and I don't even care if it exists by default. What I *want* is to easily get rid of it when it's not appropriate for the task I am trying to accomplish and there isn't currently a way of doing that because systemd, journald, dbus, and udev are all tied into one big knot.
The ability to quickly design and produce an ASIC is hardly new or innovative here. ASICs are one of the few pieces of computing that you can get done faster if you just throw more people at the problem. Plus, I have a strong suspicion that most Bitcoin mining ASICs are Gate Array ASICs (http://www.fujitsu.com/emea/services/microelectronics/asic/asic/techprod/gatearray/) which, if my understanding of them is correct, use a bunch of standard layers and interconnect them with a few custom layers. That reduces the number of masks needed as well as reducing NRE charges and minimum quantities. Essentially, it's an FPGA where the interconnection is hard wired.
Now as to your prediction that multipurpose CPUs may go away (or become a small piece of a computer), that may turn out to be true. Special purpose ASICs to solve specific problems in high performance computing have been proposed many times, though to my knowledge, not actually built. At some point, though, someone will build one. Especially as the feature sizes stop getting smaller, going to custom logic to solve problems will be the next logical way to speed things up. However, the current generation of Bitcoin mining isn't going to be contributing anything to it.
Apparently (and this is my understanding with no inside knowledge, so take it with a grain of salt), they don't have live video telemetry from the stage during decent. They have a variety of engineering data, but to get decent video, they need to get the stage back. Given that it blew up, I'm guessing that's unlikely. Last time, they had some spotty video relayed off a tracking aircraft, but they had to wait for the aircraft to land before anyone saw it. Maybe the same will happen here? Also, as a company, I have a suspicion that they aren't thrilled with releasing videos of their rockets exploding. While a lot of people here understand that that's likely inevitable, given how complex a task they're trying to achieve, the general public probably won't....