Well, informed guess. The harpoons were to be fired at 250 km/h, with good several grams of metal (I don't have the exact specs but they are about pencil-sized). That means if there's a lot of dust, they would just bury and provide some anchoring. If there's porous rock or ice, they would firmly lodge. The only case where they wouldn't work is smooth rock at angle that would cause a bounce, or rock brittle enough that the harpoons would punch a hole much larger than the hook, so it wouldn't hold. Generally a pretty good chance to get it working.
@esa_rosetta and @Philae2014 are popular-PR accounts for fun, relaxed reporting, supposed to chat with each other - something kids can watch.
@esaoperations is the team responsible for delivering the lander to the destination, so it's your primary source of news on the landing itself,
@esascience are the guys who operate all the scientific equipment on-board, and you'll get whatever Philae discovers from them - it's still quite a while before they have anything worthwhile to report.
@esa is organization-wide. They have quite a few more things to report than just Philae, and you will only see retweets, press notices etc from there - a secondary source.
For now, just follow @esaoperations and switch to @esascience in a couple days.
Most of Philae subsystems (like the landing system) are based on a RTX2010 processor. It's 16-bit, and in the landing system it's running at 1.7MHz, with 64K RAM, 16K PROM, and... Forth as its native "assembler"/"machine language".
Outside of its very original machine language, and being X-ray-hardened, these specs are quite typical to standard "industrial" control systems - processors running subsystems of a larger machines, controllers of CNC devices, and so on.
Considering about 3AU distance, if you set base stations 35km apart (maximum for GSM), to relay the signal from one to another, you'd need some 12,000,000 of them. If you spent all of the budget on base stations, they'd have to be priced about 116 euro/piece.
Currently the landing will take place at 15:34 UTC, five minutes for landing operations (harpoons, engine firing to prevent rebound), then first photos will be taken and broadcast, with the signal's arrival 28 minutes later. So, 16:02 UTC for telemetry data, 16:07 for first imagery.
About 20 minutes tolerance for automated decisions/adjustments is allowed, but the tolerance is not expected to be used really.
a) Data transfer is the primary cost of keeping them working. The station connects once per 10 minutes to send in its measurements and very little more. Adding system logs etc would triple the transfer.
b) That would double or more the unit costs. They are a simple SBC, with GPRS modem and several sensors. Keeping them simple keeps them robust - they fail extremely rarely. They often operate in very limited power conditions (solar battery + accumulators). So any extra hardware on-site is likely to be liability more than a boon. Especially that theft and vandalism is more common than normal failures.
c) Usually the entity maintaining them is different than the entity installing them, which is different than the entity purchasing them. And 4 years later you can expect the entity maintaining them has changed twice, and any service equipment/data we have provided is long lost. When working with the 3rd party we must depend on generic software and whatever we loaded the station's SBC with. We absolutely can't count on them having a specific kind of hardware.
No. Embedded is a wide range of devices. Your phone is one data point in a huge cloud. The fact it can do something means fucking nothing. I just provided another data point to disprove your fallacy that "if it works for me, it's fine, since apparently it works for everyone".
Try to guide over the phone a 3rd party serviceman who can barely type, sitting in a drizzle by a backroad 600km away, to download a systemd log reader for Windows XP to his 10-years-old laptop with slowly dying battery, over nearly-nonexistent GPRS link, when you need to debug a problem with a roadside weather station. If I fail, it's a 600km service trip for me.
Every computer comes with plain text editor, even Notepad.exe can read plaintext logs.
Thanks. I'm running TS-Linux on TS-7260 single board computer. It has 64MB RAM, 16MB Flash and 200MHz CPU. Roughly 20MB is occupied by the dedicated application the board is running, another 16MB goes to all of the OS plus server processes.
It looks like Systemd wouldn't even be able to start up on this system.
Binary logging is actually a bane. If the system crashes hard, so hard it won't boot up to recovery, I take out the drive, mount it on my PC and read the logs. Now if I have binary logs, I need tools to read them. Which means likely the same system as the one just crashed. And if the crash was due to some worm infection, ouch, I have two dead systems and nothing to read the logs with...
Pidfile is a pretty simple approach to singleton-like behavior of a service. Check for pidfile, if other than own, check for process under that pid, treat it as master/server, and pass whatever commands you had to it, then quit. If the pidfile is absent or no master resides under its pid, create/overwrite it and become master yourself.
That's not the only possible approach but it's much simpler than elections/arbitration and searching the whole process table for other instances of self or otherwise advertizing yourself to other instances.
Otherwise, a pidfile tends to be a handy tool for companion scripts/tools, but far from essential.
Of course _most_ sysadmins would rather have the best of both worlds: be notified of the problem, and have the process restarted ASAP if that was one-off, but not over and over, if the problem persists.
Someone gave a reasonable example before. Someone fuzzing your server to gain access.
If you keep restarting your server, they will eventually get in. And then they can cost you a multi-day recovery operation. Not system recovery; it will be a matter of restoring it from backups. But of legal recovery: stolen user data, undoing fraudulent transactions, recompensing users for lost assets, damage control in the PR department... the system damage will be the least of your worries.
If you think the cartoons from 70s were crap, that means the Iron Curtain worked well, "protecting" the west from any positive imagery from the Eastern Bloc.
You should really watch some toons made in Poland, Czechoslovakia, Soviet Union. Dozens of excellent, funny, well-animated toons that were friendly, didn't promote violence, and were fun to watch even for adults. Reksio, Wolf and Hare (Nu pogodi!), Krteek, and lots of other titles that would leave Hana Barbera in the dust and could easily compete with Disney's shorts - if only given a chance.
Yes. We are restricting your freedom to restrict freedoms of others. In particular, we are imposing a very small restriction, which prevents you from imposing arbitrarily large restrictions on others.
Are you going to cry foul that the government is restricting your freedom to force people into slavery?
Swap file in RAM? I always thought that's a kind of in-joke. Something like that marathon runner carrying bricks, so that he could drop them before the last mile for extra boost.
Professionalism is primarily doing your job correctly.
Stuff like good behavior, dress code or good relations are all secondary to that.
If you lack in the latter cases, you may be in for a mild reprimand. If you regularly fuck up the former - oh well, Linux is unable to fire a GCC developer, so he goes for the next best thing in that situation.
Without root privleges, and with properly set up security? Because of course there are things like 'drivers in the userspace' where the user can create a blocking function where one that's supposed to return immediately should go, and obviously these can hardlock the kernel. But you need root to do that.
Slashdot Mirror
Well, informed guess. The harpoons were to be fired at 250 km/h, with good several grams of metal (I don't have the exact specs but they are about pencil-sized).
That means if there's a lot of dust, they would just bury and provide some anchoring. If there's porous rock or ice, they would firmly lodge. The only case where they wouldn't work is smooth rock at angle that would cause a bounce, or rock brittle enough that the harpoons would punch a hole much larger than the hook, so it wouldn't hold. Generally a pretty good chance to get it working.
Actually, the split is lesser.
@esa_rosetta and @Philae2014 are popular-PR accounts for fun, relaxed reporting, supposed to chat with each other - something kids can watch.
@esaoperations is the team responsible for delivering the lander to the destination, so it's your primary source of news on the landing itself,
@esascience are the guys who operate all the scientific equipment on-board, and you'll get whatever Philae discovers from them - it's still quite a while before they have anything worthwhile to report.
@esa is organization-wide. They have quite a few more things to report than just Philae, and you will only see retweets, press notices etc from there - a secondary source.
For now, just follow @esaoperations and switch to @esascience in a couple days.
Actually, as news show, they can't. But two bounces later they are landed okay.
By now ESA has scored three successful comet landings.
With the same lander, on the same comet.
I think that's cheating,
Most of Philae subsystems (like the landing system) are based on a RTX2010 processor. It's 16-bit, and in the landing system it's running at 1.7MHz, with 64K RAM, 16K PROM, and... Forth as its native "assembler"/"machine language".
Outside of its very original machine language, and being X-ray-hardened, these specs are quite typical to standard "industrial" control systems - processors running subsystems of a larger machines, controllers of CNC devices, and so on.
Considering about 3AU distance, if you set base stations 35km apart (maximum for GSM), to relay the signal from one to another, you'd need some 12,000,000 of them. If you spent all of the budget on base stations, they'd have to be priced about 116 euro/piece.
I don't think you can buy a BTS for 116 euro.
Currently the landing will take place at 15:34 UTC, five minutes for landing operations (harpoons, engine firing to prevent rebound), then first photos will be taken and broadcast, with the signal's arrival 28 minutes later. So, 16:02 UTC for telemetry data, 16:07 for first imagery.
About 20 minutes tolerance for automated decisions/adjustments is allowed, but the tolerance is not expected to be used really.
That's all very optimistic approach.
a) Data transfer is the primary cost of keeping them working. The station connects once per 10 minutes to send in its measurements and very little more. Adding system logs etc would triple the transfer.
b) That would double or more the unit costs. They are a simple SBC, with GPRS modem and several sensors. Keeping them simple keeps them robust - they fail extremely rarely. They often operate in very limited power conditions (solar battery + accumulators). So any extra hardware on-site is likely to be liability more than a boon. Especially that theft and vandalism is more common than normal failures.
c) Usually the entity maintaining them is different than the entity installing them, which is different than the entity purchasing them. And 4 years later you can expect the entity maintaining them has changed twice, and any service equipment/data we have provided is long lost. When working with the 3rd party we must depend on generic software and whatever we loaded the station's SBC with. We absolutely can't count on them having a specific kind of hardware.
No. Embedded is a wide range of devices. Your phone is one data point in a huge cloud. The fact it can do something means fucking nothing.
I just provided another data point to disprove your fallacy that "if it works for me, it's fine, since apparently it works for everyone".
Try to guide over the phone a 3rd party serviceman who can barely type, sitting in a drizzle by a backroad 600km away, to download a systemd log reader for Windows XP to his 10-years-old laptop with slowly dying battery, over nearly-nonexistent GPRS link, when you need to debug a problem with a roadside weather station. If I fail, it's a 600km service trip for me.
Every computer comes with plain text editor, even Notepad.exe can read plaintext logs.
How do I find the master instance, say, from a tool written in shell script?
Thanks. I'm running TS-Linux on TS-7260 single board computer. It has 64MB RAM, 16MB Flash and 200MHz CPU. Roughly 20MB is occupied by the dedicated application the board is running, another 16MB goes to all of the OS plus server processes.
It looks like Systemd wouldn't even be able to start up on this system.
Does it have less than 64MB RAM and less than 200MHz CPU?
If not, shut up.
Binary logging is actually a bane.
If the system crashes hard, so hard it won't boot up to recovery, I take out the drive, mount it on my PC and read the logs.
Now if I have binary logs, I need tools to read them. Which means likely the same system as the one just crashed. And if the crash was due to some worm infection, ouch, I have two dead systems and nothing to read the logs with...
Pidfile is a pretty simple approach to singleton-like behavior of a service. Check for pidfile, if other than own, check for process under that pid, treat it as master/server, and pass whatever commands you had to it, then quit. If the pidfile is absent or no master resides under its pid, create/overwrite it and become master yourself.
That's not the only possible approach but it's much simpler than elections/arbitration and searching the whole process table for other instances of self or otherwise advertizing yourself to other instances.
Otherwise, a pidfile tends to be a handy tool for companion scripts/tools, but far from essential.
Of course _most_ sysadmins would rather have the best of both worlds: be notified of the problem, and have the process restarted ASAP if that was one-off, but not over and over, if the problem persists.
Of course systemd can't do either of these.
Someone gave a reasonable example before. Someone fuzzing your server to gain access.
If you keep restarting your server, they will eventually get in. And then they can cost you a multi-day recovery operation. Not system recovery; it will be a matter of restoring it from backups. But of legal recovery: stolen user data, undoing fraudulent transactions, recompensing users for lost assets, damage control in the PR department... the system damage will be the least of your worries.
If you think the cartoons from 70s were crap, that means the Iron Curtain worked well, "protecting" the west from any positive imagery from the Eastern Bloc.
You should really watch some toons made in Poland, Czechoslovakia, Soviet Union. Dozens of excellent, funny, well-animated toons that were friendly, didn't promote violence, and were fun to watch even for adults. Reksio, Wolf and Hare (Nu pogodi!), Krteek, and lots of other titles that would leave Hana Barbera in the dust and could easily compete with Disney's shorts - if only given a chance.
Yes. We are restricting your freedom to restrict freedoms of others.
In particular, we are imposing a very small restriction, which prevents you from imposing arbitrarily large restrictions on others.
Are you going to cry foul that the government is restricting your freedom to force people into slavery?
Swap file in RAM?
I always thought that's a kind of in-joke. Something like that marathon runner carrying bricks, so that he could drop them before the last mile for extra boost.
How did he pronounce the asterisk?
...in 4.8.3. Then it resurfaced in 4.9.0 and .1
You're calling 'more liberal' 'more free'.
Doesn't work like that. How free is OS X (based upon BSD-licensed software)?
BSD is very permissive - to the point of permitting software being based on it ceasing to be free.
GCC is more restrictive, assuring both the license and the source spreads "virally" with the program, so the program never ceases to be free.
Amen to that.
Professionalism is primarily doing your job correctly.
Stuff like good behavior, dress code or good relations are all secondary to that.
If you lack in the latter cases, you may be in for a mild reprimand. If you regularly fuck up the former - oh well, Linux is unable to fire a GCC developer, so he goes for the next best thing in that situation.
Without root privleges, and with properly set up security?
Because of course there are things like 'drivers in the userspace' where the user can create a blocking function where one that's supposed to return immediately should go, and obviously these can hardlock the kernel. But you need root to do that.