1) He-3 isn't all that useful. It has niche applications on earth in imaging, neutron detection, and so forth, but there's not really anything that would require bulk He-3 except for hypothetical He-3 fusion reactors.
2) There are no He-3 fusion reactors.
3) There's not going to be He-3 fusion reactors. It's a solution in search of a problem. We still struggle to get D-T fusion going which is orders of magnitude easier, why would we complicate the problem (and ridiculously raise the cost) just to reduce the short-term radioactivity (emphasis: short term) - radioactivity that we can actually *use* for useful breeding purposes? And if we really wanted to reduce radioactivity, we'd just skip He-3 and go straight to p-B fusion, which actually is effectively aneutronic, versus He3-D which is just low neutronicity..
4) Only low parts-per-thousand of the moon's helium is He-3. So unless you want to be sending huge quantities of helium back for a tiny bit of He3, you've got to do bloody isotope separation on the moon.
5) Only parts per million of the lunar regolith is helium. So you have to mine and bake a *lot* to get a very little amount of of helium. Which of that, only a tiny fraction is what you actually want (#4). Meanwhile, due to the cost of getting your consumables there, your labor and parts costs on any moon colony are going to be utterly absurd.
6) We can already make He-3 here on earth. It's a byproduct of tritium decay - tritium itself being breedable from lithium. Old nuclear weapons are for example often a source of He-3. Do you know what they do with it? For a long time, they were getting rid of it, converting it back to tritium. The market for making glowy paint for watches was more than the market for anything using He-3.
He-3 mining is an excuse to travel to the moon disguised in an economic wrapper.
Sorry, but first off, you didn't meet the spec. I'll repeat:
do_something(Foo a, Bar b) (emphasis: two arguments, arbitrary size)
And:
(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
You changed the spec to try to make the task easier for you. In the real world, you can't do that. "do_something" is often, say, a library call.
Secondly, your code is broken. You're passing a pointer to a local variable as your argument to a thread, which runs asynchronously, and thus has no guarantee that the local variable will still exists when it runs.
Thank you once again for demonstrating why C is such a terrible language, as with the other attempted responses in this post. Every time people try this simple challenge for a common task, they come up with these gigantic pieces of code that leak.
BZZT! Wrong! Think: what happens if a and b are local variables and the function creating the thread returns before the lambda runs?
BZZT! Wrong yourself! And let this be a lesson to you to not be so haughty when replying. What you describe never happens. The lambda is built synchronously, but called asynchronously.
To prove it, try out the following code:
#include <iostream>
void do_something(int a, int b) { std::cout << a << b; };
int main(int argc, char** argv) {
int a = 12, b = 23;
([=](){ do_something(a,b); })(); }
Compile it with "g++ --std=c++11 -S -O4" and check out the.S file (compare it to the -O0 version too). In the -O4 version you'll see the following:
You see that? It's pushing the local values directly onto the call stack. There is no intermediary step for the lambda.
Okay, so maybe my test case was too simple? Let's complicate it.
#include <iostream> #include <stdio.h>
void do_something(int a, int b) { std::cout << a << b; };
int main(int argc, char** argv) {
int a, b;
scanf("%d", &a);
scanf("%d", &b);
std::cout << 34; #if 0
([=](){ do_something(a,b); })(); #else
do_something(a,b); #endif }
Try it again with -O4 with the if set to 0 or 1 and compare the two versions together. You'll see that they're exactly the same. In both cases, main is:
The sample code will copy a and b twice, once to put them in the lambda closure
Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.
This is the general problem with C++, in that the shortest code is often the slowest
Compared to what alternative C algorithm? Still waiting here....;)
Beyond that, that's not how you optimize a program. You don't try to optimize the heck out of every last line; that's a recipe for an unmaintainable mess that's not actually that fast. You write clean, organized code, you profile it, and then you optimize where the profiling data tells you that you can make the biggest improvement. Trying to be "clever" and outsmart the compiler with every line of code "in the interest of performance" is how spaghetti code gets made
The slowness is visible in C, where you would probably
To reiterate my first post:
Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description
Yes, I knew exactly that people like you would come in and try to pass off a rough description as an implementation. The reality is that the implementation is such an utter, bug-prone PITA in C (compared to a trivial command in C++) that most people don't even bother. Which means that code gets underthreaded, which means that it performs terrible and is prone to lockups.
STL and lambda are my main reasons for using C++. They're bloody awesome.
Here's my standard challenge for C people - I've given it many times in these sort of threads and not once gotten a real response that meets the specs. Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description), full code (emphasis: full) for a program launching a detached (emphasis: detached) thread, such that it can happen an arbitrary number of times with no guarantee that other threads will be done (emphasis, there can be more than one thread at a time), to run the function do_something(Foo a, Bar b) (emphasis: two arguments, arbitrary size) - where the values passed for a and b are variables local to the context that launches the thread (emphasis: local), so they need to be passed by copy, not reference.
This is not at all some sort of esoteric task - launching threads with nontrivial local arguments is pretty basic, there's millions of use cases for something like this. Here it is in C++11:
Little short line of code. Surely for such an obvious, non-esoteric task, C can't be much harder, right? Any takers?
(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
Honestly, I find a random program written in C to be on average FAR less maintainable than one written in C++, usually because they end up reinventing the wheel about 50 times, usually poorly. The C program that I work on at work is one gigantic mass of poor wheel reinvention over and over again. Its impersonation of objects and inheritance (for sending message) is terrible, utterly terrible, it's almost impossible to build and send a message without messing up in some way due to all of the interconnected pointers. The macros they use to try to "simplify" it only make it worse. Some parts of the code have macros nested literally dozens of levels deep.
Really, it's hard to picture a data format that's pretty much the standard for the era ever become totally unreadable, so long as the data is intact. Our tech today is going to be stone-age primitive to people of the future. They will be able to read it. They may need to send it off to a special service, but they will get the data. And since the data should remain intact on M-disc and it's compatible with DVD, it should be the best choice.
Anyway, regardless of the physical formats the data goes in (and realistically, it should go in as many formats as possible), probably the most critical task is protecting the capsule itself. Aka, as deep as possible to have it always be cool and never experience temperature swings, and with waterproofing that will last 50-100 years (as someone who's been working on that for a personal project recently, your answer is "SBS modified bitumen membrane", aka rubberized asphalt sheets, as many layers as you can; almost everything else will eventually become brittle and subject to leaking due to temperature changes, ground settling, etc)
I wonder how cheap it is. Because, couldn't something like this really be first step towards all of those "everything is a computer screen" techs you always see in sci-fi, like fliers with full motion animation and the like? If a whole display can be laid out with an affordable ink, then the only issues in the way of ubiquity are 1) power, and 2) the input signal. A flexible printable battery could enable #1 (just have it as the first layer of your screen), and/or a printed solar cell. #2 would require either low cost computing hardware... or conversely, perhaps just a simple rf receiver for some protocol which cell phones can transmit and a unique broadcast code for the content to be displayed on the screen. The user's cell could thus function as the computing hardware, downloading the appropriate code to run in a sandbox, like javascript on a website, with the trigger being the user touching the product.
We've grown accustomed to products having what's written on them be fixed but the potential for what they could display is almost unlimited - if the cost of the display, computing, and basic sensors could be kept low enough. A milk carton letting you know when it's gone bad. A piece of cable warning you that it's corroded on the inside and its resistance has gone outside of design parameters. A cereal box having its product information printed in the language you speak. A simple mechanical wrench that nonetheless tells you how much force you're applying. Etc.
If the cost of adding that sort of stuff drops far enough below the cost of the product, people will start to add it everywhere (sort of like what happened with LED indicator lights). And yeah, of course just like with LEDs some manufacturers will overdo it and get annoying. But overall it'll still be a good thing. Let's not forget that LED indicators lights can be very useful. I have an old MIG welder from the 1960s or 1970s. I thought it was broken for a couple days until I discovered that the torch just wasn't pushed in far enough and wasn't getting a good connection. There was not a light or any other sort of indicator showing that the thing was even getting power, let alone working - I had to go in with a multimeter and probe one connection after another until I saw that everything was fine except for the trigger connection. A handful of indicator LEDs would have told me that immediately. They could have of course used small incandescent bulbs back then, or other such lighting technology. But we all know those would have burned out long ago and nobody would have bothered to replace them, and they would have cost a lot more more than modern LEDs - so they didn't bother.
One day, cheap low-cost displays may be as ubiquitous as indicator LEDs have become.
You can do anything the Yik Yak app can do. You can post messages, upvote messages as well as downvote them. I must note that there's really no true verification that happens here, it's all crappy PHP scripts all hidden behind SSL.
I'm sure you can figure out if I've used the API or not already, but I will say this is really abusable and can be used to do just about anything as well.
Want a username on Yik Yak (a handle) without having to ask people to redeem your code? All you need to write some code to redeem your code 4 times from different user IDs and bam.
Want to delete a comment or message off Yik Yak? You can downvote that comment/message so many times (with different user ids) and eventually it'll be ripped off the face of the earth.
Want to know the top Yik Yaks posted in an area? You can exactly do that. I was planning on making an publicly available service that you were able to pin a specific area/location and get all the top messages in that area, but got too lazy.
I'm giving you all the possibilities because I'm sure nobody will be utilizing this API anytime soon.
That would be great if we lived in a world where people don't actually commit rape. Meanwhile, in the real world, it's actually disturbingly common. Just because you see someone proposing a gang rape behind a veil of anonymity doesn't mean that they were just joking. It's eminently possible that they were 100% serious.
Anyway, while this is portrayed as something that universities physically can't do anything about without going to court, there's actually a number of things they could do, from a technical standpoint. For example, if the comments are being made through university networks, they could be sniffed and logged. Even if they're encrypted (I don't know how the YikYak protocol works), they could be correlated by timestamp. Posting threats could be made (and probably already is) a violation of the network TOS, and reason to suspect a violation of the TOS cause to inspect the logs. This wouldn't (and probably legally couldn't) be done in secret, it would have to be publicly stated in the TOS that users have to agree to in order to use the network (all universities have acceptable use policies), that any network data can be logged and stored, with access to the logs granted only for review in the event of a suspected TOS violation.
It of course wouldn't help if it was say posted via a cell phone. But it would catch some cases. There may be other weaknesses in how YikYak works that would help catch people.
*Sigh*. It's just the scale, whether it's based on 100% or a figure of absolute newtons. It doesn't change things.
It's a simple fact. Tire drag drops as tires heat up. Trust me, I used to make vehicle modeling software. Normal road tires never become literally "sticky" to the point of becoming tacky to the touch and holding the car back. The prime source of energy loss in a tire is the rubber bending. The tire deforms where it meets the ground - the lower the pressure, the more it deforms. At high speeds tires also begin to develop standing waves which provide for more even more deformation. The repeated bending of the rubber forward and backward becomes heat and resists the rolling motion. The hotter the rubber, the lower the resistance.
Literally getting "sticky" has little to no effect in real-world conditions for normal road tires.
Tires actually get more efficient as they get hot. You don't want to be cooling your tires. Heat raises the internal pressure and it makes the rubber more flexible, both of which reduce rolling losses. Really, really stupid idea, taking the heat away for a tiny bit of thermoelectric power.
That said, the OTHER tire mentioned in the article - the concept multitube tire that can change its drive characteristics based on conditions - actually could be a major improvement if paired with a smart control system. If you could have a tire that runs on 100 PSI in smooth, high traction conditions, but can have you riding on super sticky studded rubber in bad conditions / cornering / high accel / decel, gives you the best of all worlds - a tiny rolling drag coefficient most of the time but high safety right when it's needed. Rolling losses are the largest loss factor for in-city driving and make up about a quarter to a third of highway losses, so the ability to dramatically reduce them means no small gain for vehicle efficiency.
Generally while doing this, I don't pause to consider how that blue dot on a screen is a function of at network of multi-million-dollar satellites in space sending signals to and receiving signals from my phone
So far they're calling this an early H. habilis. That may change with further study or it may get a subspecies designator, but for now at least, it's H. habilis.
How do you expect a single state to say that you aren't married in another without another interstate/federal database
So you find the government actually keeping track of vital records and legal statuses to be overintrusive and to be "spying and tracking how you live your life"?
Okay, I'm going to go have a conversation with rational people now....
While the whole "robot" aspect is just style, I think the main point to respect is that they have moving low-light cameras. So the robot may not come and arrest you for a major violation, but the police might.
Anyway, while it's a bit gimmicky, I think it's just so great to see such a stereotypically 3rd world country supporting people learning engineering in that manner. DRC is the last place on earth one would expect government funding for an association of womens' engineers making robots. Maybe some day they'll even end up with some viable export products, or establish enough of an educated base to attract multinationals looking for low-cost engineering talent like India has long worked to do.
Actually you can't just turn your passport in. You have to pay hundreds of dollars to formally renounce. And you can only do so if you're already a foreign citizen.
My first year in Iceland, my US return was so complex that most tax attorneys refused to touch it. One offered to do it for over $1000. I ended up doing it myself. Three years later I'm still dealing with the IRS on it. It was as thick as a book.
My subsequent returns have been simpler but are still really annoying.
Seriously, don't do this to your kids. Just don't.
It's not even just taxes. The US is so weird about all sorts of things that can bite you. When I got engaged in Iceland, Iceland wanted a certificate from the US proving that I'm not already married - it's a standard requirement here, and most countries have such a certificate. But not the US! In the US you can get a certificate proving that you are married from the state you got married in, but not a certificate proving that you're not married. The only way around it is to find the one sherrif's office in the country who considers a signed affadavit to be sufficient to wed (all of the others disagree).
I would never dream of cursing my kids with US citizenship. How mean could you be to them? I can't bloody wait to get my Icelandic citizenship so that I can formally renounce my US citizenship.
1. Alibaba.com. You can get anything there. 2. Semipermanent subplate attached to the table with pin slots, surgical grade titanium plate pinned into position, pancreas stock welded into place with TIG set to the settings for pancreas stock of appropriate thickness (what can't you weld with TIG?) 3. We find the mechanical properties of billet pancreas to be sufficient, and the higher precision and better finish reduce the odds of customer rejection.
"3d printing" is the latest fad for Slashdotters to obsess over; meanwhile, in the real world, people are just going to use more established solutions. For example, where I work we're making great progress towards CNC-milling a pancreas.
Slashdot Mirror
And lunar He-3 mining is pretty useless.
1) He-3 isn't all that useful. It has niche applications on earth in imaging, neutron detection, and so forth, but there's not really anything that would require bulk He-3 except for hypothetical He-3 fusion reactors.
2) There are no He-3 fusion reactors.
3) There's not going to be He-3 fusion reactors. It's a solution in search of a problem. We still struggle to get D-T fusion going which is orders of magnitude easier, why would we complicate the problem (and ridiculously raise the cost) just to reduce the short-term radioactivity (emphasis: short term) - radioactivity that we can actually *use* for useful breeding purposes? And if we really wanted to reduce radioactivity, we'd just skip He-3 and go straight to p-B fusion, which actually is effectively aneutronic, versus He3-D which is just low neutronicity..
4) Only low parts-per-thousand of the moon's helium is He-3. So unless you want to be sending huge quantities of helium back for a tiny bit of He3, you've got to do bloody isotope separation on the moon.
5) Only parts per million of the lunar regolith is helium. So you have to mine and bake a *lot* to get a very little amount of of helium. Which of that, only a tiny fraction is what you actually want (#4). Meanwhile, due to the cost of getting your consumables there, your labor and parts costs on any moon colony are going to be utterly absurd.
6) We can already make He-3 here on earth. It's a byproduct of tritium decay - tritium itself being breedable from lithium. Old nuclear weapons are for example often a source of He-3. Do you know what they do with it? For a long time, they were getting rid of it, converting it back to tritium. The market for making glowy paint for watches was more than the market for anything using He-3.
He-3 mining is an excuse to travel to the moon disguised in an economic wrapper.
...the bug that prevents me from having accelerated graphics in Linux, I'd be among that 1%. Until then? Reboot... reboot.... reboot... reboot...
Sorry, but first off, you didn't meet the spec. I'll repeat:
And:
You changed the spec to try to make the task easier for you. In the real world, you can't do that. "do_something" is often, say, a library call.
Secondly, your code is broken. You're passing a pointer to a local variable as your argument to a thread, which runs asynchronously, and thus has no guarantee that the local variable will still exists when it runs.
Thank you once again for demonstrating why C is such a terrible language, as with the other attempted responses in this post. Every time people try this simple challenge for a common task, they come up with these gigantic pieces of code that leak.
BZZT! Wrong yourself! And let this be a lesson to you to not be so haughty when replying. What you describe never happens. The lambda is built synchronously, but called asynchronously.
To prove it, try out the following code:
Compile it with "g++ --std=c++11 -S -O4" and check out the .S file (compare it to the -O0 version too). In the -O4 version you'll see the following:
You see that? It's pushing the local values directly onto the call stack. There is no intermediary step for the lambda.
Okay, so maybe my test case was too simple? Let's complicate it.
Try it again with -O4 with the if set to 0 or 1 and compare the two versions together. You'll see that they're exactly the same. In both cases, main is:
Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.
Compared to what alternative C algorithm? Still waiting here.... ;)
Beyond that, that's not how you optimize a program. You don't try to optimize the heck out of every last line; that's a recipe for an unmaintainable mess that's not actually that fast. You write clean, organized code, you profile it, and then you optimize where the profiling data tells you that you can make the biggest improvement. Trying to be "clever" and outsmart the compiler with every line of code "in the interest of performance" is how spaghetti code gets made
To reiterate my first post:
Yes, I knew exactly that people like you would come in and try to pass off a rough description as an implementation. The reality is that the implementation is such an utter, bug-prone PITA in C (compared to a trivial command in C++) that most people don't even bother. Which means that code gets underthreaded, which means that it performs terrible and is prone to lockups.
Threading is of course just the start here...
STL and lambda are my main reasons for using C++. They're bloody awesome.
Here's my standard challenge for C people - I've given it many times in these sort of threads and not once gotten a real response that meets the specs. Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description), full code (emphasis: full) for a program launching a detached (emphasis: detached) thread, such that it can happen an arbitrary number of times with no guarantee that other threads will be done (emphasis, there can be more than one thread at a time), to run the function do_something(Foo a, Bar b) (emphasis: two arguments, arbitrary size) - where the values passed for a and b are variables local to the context that launches the thread (emphasis: local), so they need to be passed by copy, not reference.
This is not at all some sort of esoteric task - launching threads with nontrivial local arguments is pretty basic, there's millions of use cases for something like this. Here it is in C++11:
std::thread([=](){ do_something(a,b); )).detach();
Little short line of code. Surely for such an obvious, non-esoteric task, C can't be much harder, right? Any takers?
(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
Honestly, I find a random program written in C to be on average FAR less maintainable than one written in C++, usually because they end up reinventing the wheel about 50 times, usually poorly. The C program that I work on at work is one gigantic mass of poor wheel reinvention over and over again. Its impersonation of objects and inheritance (for sending message) is terrible, utterly terrible, it's almost impossible to build and send a message without messing up in some way due to all of the interconnected pointers. The macros they use to try to "simplify" it only make it worse. Some parts of the code have macros nested literally dozens of levels deep.
Really, it's hard to picture a data format that's pretty much the standard for the era ever become totally unreadable, so long as the data is intact. Our tech today is going to be stone-age primitive to people of the future. They will be able to read it. They may need to send it off to a special service, but they will get the data. And since the data should remain intact on M-disc and it's compatible with DVD, it should be the best choice.
Anyway, regardless of the physical formats the data goes in (and realistically, it should go in as many formats as possible), probably the most critical task is protecting the capsule itself. Aka, as deep as possible to have it always be cool and never experience temperature swings, and with waterproofing that will last 50-100 years (as someone who's been working on that for a personal project recently, your answer is "SBS modified bitumen membrane", aka rubberized asphalt sheets, as many layers as you can; almost everything else will eventually become brittle and subject to leaking due to temperature changes, ground settling, etc)
I wonder how cheap it is. Because, couldn't something like this really be first step towards all of those "everything is a computer screen" techs you always see in sci-fi, like fliers with full motion animation and the like? If a whole display can be laid out with an affordable ink, then the only issues in the way of ubiquity are 1) power, and 2) the input signal. A flexible printable battery could enable #1 (just have it as the first layer of your screen), and/or a printed solar cell. #2 would require either low cost computing hardware... or conversely, perhaps just a simple rf receiver for some protocol which cell phones can transmit and a unique broadcast code for the content to be displayed on the screen. The user's cell could thus function as the computing hardware, downloading the appropriate code to run in a sandbox, like javascript on a website, with the trigger being the user touching the product.
We've grown accustomed to products having what's written on them be fixed but the potential for what they could display is almost unlimited - if the cost of the display, computing, and basic sensors could be kept low enough. A milk carton letting you know when it's gone bad. A piece of cable warning you that it's corroded on the inside and its resistance has gone outside of design parameters. A cereal box having its product information printed in the language you speak. A simple mechanical wrench that nonetheless tells you how much force you're applying. Etc.
If the cost of adding that sort of stuff drops far enough below the cost of the product, people will start to add it everywhere (sort of like what happened with LED indicator lights). And yeah, of course just like with LEDs some manufacturers will overdo it and get annoying. But overall it'll still be a good thing. Let's not forget that LED indicators lights can be very useful. I have an old MIG welder from the 1960s or 1970s. I thought it was broken for a couple days until I discovered that the torch just wasn't pushed in far enough and wasn't getting a good connection. There was not a light or any other sort of indicator showing that the thing was even getting power, let alone working - I had to go in with a multimeter and probe one connection after another until I saw that everything was fine except for the trigger connection. A handful of indicator LEDs would have told me that immediately. They could have of course used small incandescent bulbs back then, or other such lighting technology. But we all know those would have burned out long ago and nobody would have bothered to replace them, and they would have cost a lot more more than modern LEDs - so they didn't bother.
One day, cheap low-cost displays may be as ubiquitous as indicator LEDs have become.
Oh hey, who'daguessed it, apparently the protocol is super-weak.
That would be great if we lived in a world where people don't actually commit rape. Meanwhile, in the real world, it's actually disturbingly common. Just because you see someone proposing a gang rape behind a veil of anonymity doesn't mean that they were just joking. It's eminently possible that they were 100% serious.
Anyway, while this is portrayed as something that universities physically can't do anything about without going to court, there's actually a number of things they could do, from a technical standpoint. For example, if the comments are being made through university networks, they could be sniffed and logged. Even if they're encrypted (I don't know how the YikYak protocol works), they could be correlated by timestamp. Posting threats could be made (and probably already is) a violation of the network TOS, and reason to suspect a violation of the TOS cause to inspect the logs. This wouldn't (and probably legally couldn't) be done in secret, it would have to be publicly stated in the TOS that users have to agree to in order to use the network (all universities have acceptable use policies), that any network data can be logged and stored, with access to the logs granted only for review in the event of a suspected TOS violation.
It of course wouldn't help if it was say posted via a cell phone. But it would catch some cases. There may be other weaknesses in how YikYak works that would help catch people.
I'm betting that Freon leaks. And that it destroys its operating environment.
*Sigh*. It's just the scale, whether it's based on 100% or a figure of absolute newtons. It doesn't change things.
It's a simple fact. Tire drag drops as tires heat up. Trust me, I used to make vehicle modeling software. Normal road tires never become literally "sticky" to the point of becoming tacky to the touch and holding the car back. The prime source of energy loss in a tire is the rubber bending. The tire deforms where it meets the ground - the lower the pressure, the more it deforms. At high speeds tires also begin to develop standing waves which provide for more even more deformation. The repeated bending of the rubber forward and backward becomes heat and resists the rolling motion. The hotter the rubber, the lower the resistance.
Literally getting "sticky" has little to no effect in real-world conditions for normal road tires.
That is incorrect.
Tires actually get more efficient as they get hot. You don't want to be cooling your tires. Heat raises the internal pressure and it makes the rubber more flexible, both of which reduce rolling losses. Really, really stupid idea, taking the heat away for a tiny bit of thermoelectric power.
That said, the OTHER tire mentioned in the article - the concept multitube tire that can change its drive characteristics based on conditions - actually could be a major improvement if paired with a smart control system. If you could have a tire that runs on 100 PSI in smooth, high traction conditions, but can have you riding on super sticky studded rubber in bad conditions / cornering / high accel / decel, gives you the best of all worlds - a tiny rolling drag coefficient most of the time but high safety right when it's needed. Rolling losses are the largest loss factor for in-city driving and make up about a quarter to a third of highway losses, so the ability to dramatically reduce them means no small gain for vehicle efficiency.
(Morbo voice) "GPS Does Not Work That Way!!!"
So far they're calling this an early H. habilis. That may change with further study or it may get a subspecies designator, but for now at least, it's H. habilis.
And they made my coffee get cold too! Damn those "scientists"! I heard they're responsible for getting Firefly cancelled also.
So you find the government actually keeping track of vital records and legal statuses to be overintrusive and to be "spying and tracking how you live your life"?
Okay, I'm going to go have a conversation with rational people now....
While the whole "robot" aspect is just style, I think the main point to respect is that they have moving low-light cameras. So the robot may not come and arrest you for a major violation, but the police might.
Anyway, while it's a bit gimmicky, I think it's just so great to see such a stereotypically 3rd world country supporting people learning engineering in that manner. DRC is the last place on earth one would expect government funding for an association of womens' engineers making robots. Maybe some day they'll even end up with some viable export products, or establish enough of an educated base to attract multinationals looking for low-cost engineering talent like India has long worked to do.
Actually you can't just turn your passport in. You have to pay hundreds of dollars to formally renounce. And you can only do so if you're already a foreign citizen.
My first year in Iceland, my US return was so complex that most tax attorneys refused to touch it. One offered to do it for over $1000. I ended up doing it myself. Three years later I'm still dealing with the IRS on it. It was as thick as a book.
My subsequent returns have been simpler but are still really annoying.
Seriously, don't do this to your kids. Just don't.
It's not even just taxes. The US is so weird about all sorts of things that can bite you. When I got engaged in Iceland, Iceland wanted a certificate from the US proving that I'm not already married - it's a standard requirement here, and most countries have such a certificate. But not the US! In the US you can get a certificate proving that you are married from the state you got married in, but not a certificate proving that you're not married. The only way around it is to find the one sherrif's office in the country who considers a signed affadavit to be sufficient to wed (all of the others disagree).
I would never dream of cursing my kids with US citizenship. How mean could you be to them? I can't bloody wait to get my Icelandic citizenship so that I can formally renounce my US citizenship.
1. Alibaba.com. You can get anything there.
2. Semipermanent subplate attached to the table with pin slots, surgical grade titanium plate pinned into position, pancreas stock welded into place with TIG set to the settings for pancreas stock of appropriate thickness (what can't you weld with TIG?)
3. We find the mechanical properties of billet pancreas to be sufficient, and the higher precision and better finish reduce the odds of customer rejection.
"3d printing" is the latest fad for Slashdotters to obsess over; meanwhile, in the real world, people are just going to use more established solutions. For example, where I work we're making great progress towards CNC-milling a pancreas.