Most likely the bullies are members of the school's football team, hence the protection afforded to them.
So option three, but targeting the Achilles heel tendon or other sport-critical tendon/muscle, is a great option, in my opinion.
Clearly the school has a bullying problem, and a control problem. It's a sick, diseased school run by weak people, and teachers too afraid to do their job to protect students from bullies who are on the school football team. This is something that requires state intervention, I presume the state has school inspection bodies, and the ability to enact punishments? I would suggest a ban in intra-school sporting competition for a couple of years until the school's curriculum has moved back towards education.
Indeed, I think that US school sports is really weirdly venerated. I'd split the two up, schools can have basic sport, but clubs, etc, should be run outside of the school, maybe with loose affiliation, but having no influence on the school's central reason for existence - education.
Even better, you could probably find a million people willing to pay money to have their DNA stored for use on future colony planets. That could help fund this space programme, a little.
The cost and availability of storage for these genomes isn't really the issue. The automated human-building factories are an issue (synthetic wombs, etc, will probably be a solved issue by the time we can build a 300-year lifespan spacecraft carrying hundreds of people - the surrogate mother issue will probably not be an issue), and the subsequent raising of these children will require real human contact - hence the point of this article which is getting those humans to the end of the journey in a reliable manner (those humans will also monitor and repair the spacecraft during the voyage, even if automated processes are good enough for most problems).
I believe that was meant to be around 80,000 years ago.
That's a pretty serious long-term colonisation programme. I wouldn't want HP building the computers they needed to last through this process.
A large portion of any spaceship is going to be storage for end-of-journey supplies, and fabrication robots (that fabricate bigger fabricators, etc, until you have colony-builders).
Small villages traded with other small villages, they didn't exist in a vacuum. These people will, however many exabytes of media you supply them with to keep themselves occupied. 150 people have a high risk, on a 300 year journey, of being wiped out, or decimated to a level they can't recover from. 500 people is better, 2000 is nearly okay, 10,000 is basically great, 40,000 is excellent. A convoy of ships is better than a single ship (which makes the single giant asteroid spaceship idea a bit less desirable).
Who's going to look after the embryo children if the generational population died out, or are crippled by genetic defects?
That's why you need on-ship genetic variation. The on-ship population needs to survive, year after year, century after century.
Sure, the idea that the ship also hatches embryos en-route in case of gaps is fine, except for the catastrophe case (decimation of the population means the population is too weak or non-existent to even raise the in-ship hatchlings).
It seems that 2000 people is a strong enough population, especially if spread over several different spaceships travelling in convoy (which also helps with the Dunbar's number issue). But 150, or 500, is not enough.
Or you wait long enough until spaceships are fast enough to allow the people who want to populate another planet to be the ones who arrive there and populate it. Advances in cryogenic sleep may allow this.
figure out how to introduce additional genetic diversity once you arrive and establish yourselves.
Keeping to the spirit of the original article (i.e., ignoring embyros and overloading the workload of the colonists to also raise loads of children on the side, rather than just a few children), that could mean staggering the launch of each of the ships, rather than launching together.
By the time the second ship arrives, the crew of the first ship are either all dead (and their roles fall to the second ship), or the first ship has prepared the optimal landing site with all the facilities, cleared the lands for the orchards (which will be mature by the time the second ship arrives) and agricultural needs, and have enough information on living on the new planet to get the new colonisers up to speed rapidly.
Again, human nature is going to be a major problem. A close knit community on the ground, say for 10, or even 20 years, is probably not going to welcome the next spaceship load of humans. But they would like the tools and seeds and animals and facilities they have. There is a strong chance that instead of one large colony, you'd end up with multiple, small, separated colonies. Maybe close enough to trade and therefore amalgamate one day...
And if you don't think that 150 humans (however advanced and brilliant their on-ship education and upbringing is) aren't going to be selfish and decide that they would rather raise their own children than 10,000 "other peoples" children then you've got another thing coming. It's not like anyone is going to be able to punish them for making a decision like this either.
Disregarding that, these 150 people will be spread over a range of ages and capabilities too. So maybe there will be 50 couples capable of raising an additional child every three years, for the rest of their lives. I.e., you can probably hatch up to 20 additional children a year from the 10,000 at most. Which isn't an ideal rate, I would assume that the extra genetic diversity such a small injection provides would be lost. That's if they're not excluded from society as being "others", blah blah human nature, etc. Of course the population would increase rapidly, so the rate of hatching could increase too.
But then you need people to actually build the civilisation on the new planet. Agriculture, Buildings, Defences. I'm sure the initial landing fleet (for humans and end-of-journey world-building supplies) would suffice initially, but even so a sizeable portion of the population is going to be engaged in colonisation, not parenthood.
Maybe 2000 people + 10,000 embryos would work better. Keeping 2000 people entertained on their asteroid based spaceship is going to be fun.
You would have thought that insurance companies would have been quite quick to refuse to cover the properties because of the risk. "We'll have to apply a landslide exemption to this cover" should ring alarm bells, just as "We won't cover flood damage" should be taken to mean "we expect your house to flood" because it's built on a flood plain. Yet people still buy houses on flood plains and then complain bitterly to the media when their house floods.
I don't understand why they didn't just add a "variables" CSS key.
e.g.:
div {
variables: {
color: #000000;
};
padding: 0px; }
div.header {
color: var(color); }
TBH I don't even think they need to be "variables", just "cascading named constants". And ultimately, because CSS hasn't supported such a feature before, even though back in the 90s people were saying how nice it would be to have such a feature, we have various pre-processors/template driven CSS/in-house solutions.
Yes, hyper-specialism is a problem, as is unwillingness to learn new things. Those Flash devs will not go far unless they push their boundaries.
SVN is not hard. Git is not hard, but a little more complex up front than svn checkout/update/commit. Any intelligent person can get their heads around these in a couple of hours, especially when someone is willing to help them or sit with them through a sample session (an essential part of mentoring).
And which framework was that? If it's targeted at "enterprise" use, then speed and efficiency won't be one of its core features, not with runtime annotation processing...
For example, Apache Wicket is a gross bloated thing to avoid the "horror" of learning how to program a web UI in JS that communicates with the backend server using sane RESTful APIs. OTOH it saves you from writing those APIs and keeps your codebase in a single object oriented language.
Hibernate is a gross-but-cool thing that saves the developer from touching JDBC. It's overhead pales in comparison with the network latency/RTT and database effort though, and it allows the programmer to again do database operations at a decent OO high level. Personally, I prefer JDBC but that can end up with a lot of boilerplate code to do simple operations. But OTOH you could end up with dodgy DB code, failure to try/catch/finally properly, etc. HQL can DIAF.
And Spring... Spring does everything. Dependency injection is a major advantage (until you use it, you might wonder why your "EntityManager" class is not good enough), interceptors, etc. Ignore the MVC crap, that's old hat.
And tooling is another thing. Maven is essential for the Java developer today. Until I used it, I was happy with Ant and manually updating dependencies. Selenium is an essential web UI integration test tool too. Anything that makes testing, integration testing, etc, easier should be welcomed with open arms. Team-based development is a recipe for breaking code contracts in multiple places.
There are a lot of new tricks that a programmer that has stayed in a comfortable role for a long time could have missed, and find problems when looking for a new job. Luckily, a good C programmer is unlikely to be applying for Java roles, and roles are often now in the embedded marketplace where frameworks are less common over raw C with common libraries.
And there will be plenty of people that disagree with everything I've written. The joy of programming, eh?!
Vapourware is a bit harsh. There were delays, and the end result is not the miracle hardware that some people expected for $100, but they did make and ship the hardware, controllers and create an app store that had games in it. They were also up front about the Ouya hardware, and people were free to consider whether or not they thought it was good enough for a cheap small games console.
The devices run Android, and thus gain from being able to play Android games.
Ouya has its own app store where games that are optimised for the Ouya are sold. By optimised, I mean more than just targeting the hardware, but also how it is used - controller on a TV, rather than touch-screen device.
As you can imagine, this can be quite hit and miss. Additionally, the Ouya hardware fell behind the market fairly quickly because of its use of a Tegra 3 which is actually quite poor in terms of graphical power. A Tegra 4 iteration should do a lot to fix this, although a Tegra K1 would be most optimal.
If Apple cared about this market, they would stick an A7 in the next Apple TV and thrash the Ouya senseless with superior hardware, and their app store and developer mindshare (everyone would optimise their iOS games for the Apple TV fairly rapidly).
I expect that you would be eligible for the subsidy for three years, or for your first degree (for long running degrees like medicine, where higher earnings afterwards would make it well worth investing up front in free education).
I also expect that the rate of tax required to fund it (and repay the initial upfront investment) would be more than 3%.
You could also target the free education at courses that are deemed valuable to the country's economic development and future - i.e., sciences, maths, engineering, rather than media studies, equine science and history of art.
Yes, this is the sort of task-oriented dedicated function blocks for video decode and encode that have been popular in GPU, ARM SoC and now x86 "APU" for quite some time.
Useless for high quality encoding, but great for standard consumer uses, quick encoding and transcoding of all those phone videos.
The PS4 probably uses VCE for its TwitchTV integration, for example.
But the model with disk drive and 128KB RAM was $1269 on its own, $1459 with DOS and a keyboard and a keyboard cord ($20!)...
To use the decent graphics modes, which used 32KB system RAM, you needed the 128KB version. The graphics interfered with the CPU when it needed memory, slowing it down.
But it had potential, but IBM probably wasn't the company to achieve it.
It's far easier to transfer the domains away from them and not run into the problem in the first place. Let them know why you are transferring the names, of course.
In addition, the credit card chargeback facility exists for a reason. Enough of them and the company's payment merchant can choose to put a block on the company's merchant account and ability to take payments.
Most people bin them, just like most people bin batteries.
But (at least in the UK) most supermarkets have battery recycling bins - it wouldn't be hard to add a CFL recycling bin to encourage recycling once they die.
If it dies after a week, then return it on your next trip to the shop, which will undoubtedly be within the warranty period of the bulb. It's the cheap electronics they put in mass produced CFLs, that's why some die early. They seem sensitive to less than ideal electricity supplies (and temperature).
The worry is that LED bulbs and CFLs share very compact electronics, and that is what dies most of the time. Hopefully the LED bulbs currently have higher quality electronics being a premium product at the moment.
Overall, the electricity savings make up for the additional cost many times over, even if the odd bulb dies too quickly.
CFLs are evil, expensive, toxic, and they don't last anywhere near as long as the packaging claims.
Nope. How can an inert thing be "evil"? Nope. They're pretty cheap these days. Not as cheap up-front as an incandescent, but the savings in power more than make up for it. Nope. If you're talking about the trace amount of mercury, you need to consider the mercury emitted by the power station burning coal to power your 100W dinosaur of a light. Nope. Many people have 10, 20 year old CFLs still running.
Stop basing your opinions on cheap-ass CFLs sold by cost-cutting, quality-cutting retailers.
The problem with CFLs and LEDs is that they incorporate AC/DC electronics in every bulb. It is this that usually fails, rather than the bulb. Obviously, with electronics, it usually dies quick, if it's going to die, and you can take it back to the store for a replacement under warranty. The solution in the long term is that houses should have DC lighting circuits, and one, high quality, AC/DC convertor for all the sockets. Fine for new builds, but nobody will want to rewire, so the electronics in every bulb is here, probably for a long long time.
And yes, occasionally an incandescent can last a long time. And for all that time, it is burning 60W or 100W, rather than ~20W. And for this reason, the people who benefit most from up-front expensive bulbs are the poorest, as the ongoing running costs save far more than the up-front cost.
(In 100 years we will probably have people running 100 year old LED bulbs too).
LED light quality is surprisingly good as well. IMO more agreeable than CFL.
You can post all the facts you want, but some people will still be whining about their precious dangerous hot wasteful incandescents.
Maybe you should try an infographic version of your post.
Oh, and don't forget the lifespan of the LED bulbs. On a per-year basis, and an average of 15 years (or 25 years) lifespan, you're talking about 50 cents a year for the bulb itself - probably lower than the cost for incandescents given how frequently they fail.
Slashdot Mirror
Most likely the bullies are members of the school's football team, hence the protection afforded to them.
So option three, but targeting the Achilles heel tendon or other sport-critical tendon/muscle, is a great option, in my opinion.
Clearly the school has a bullying problem, and a control problem. It's a sick, diseased school run by weak people, and teachers too afraid to do their job to protect students from bullies who are on the school football team. This is something that requires state intervention, I presume the state has school inspection bodies, and the ability to enact punishments? I would suggest a ban in intra-school sporting competition for a couple of years until the school's curriculum has moved back towards education.
Indeed, I think that US school sports is really weirdly venerated. I'd split the two up, schools can have basic sport, but clubs, etc, should be run outside of the school, maybe with loose affiliation, but having no influence on the school's central reason for existence - education.
Even better, you could probably find a million people willing to pay money to have their DNA stored for use on future colony planets. That could help fund this space programme, a little.
The cost and availability of storage for these genomes isn't really the issue. The automated human-building factories are an issue (synthetic wombs, etc, will probably be a solved issue by the time we can build a 300-year lifespan spacecraft carrying hundreds of people - the surrogate mother issue will probably not be an issue), and the subsequent raising of these children will require real human contact - hence the point of this article which is getting those humans to the end of the journey in a reliable manner (those humans will also monitor and repair the spacecraft during the voyage, even if automated processes are good enough for most problems).
I believe that was meant to be around 80,000 years ago.
That's a pretty serious long-term colonisation programme. I wouldn't want HP building the computers they needed to last through this process.
A large portion of any spaceship is going to be storage for end-of-journey supplies, and fabrication robots (that fabricate bigger fabricators, etc, until you have colony-builders).
Small villages traded with other small villages, they didn't exist in a vacuum. These people will, however many exabytes of media you supply them with to keep themselves occupied. 150 people have a high risk, on a 300 year journey, of being wiped out, or decimated to a level they can't recover from. 500 people is better, 2000 is nearly okay, 10,000 is basically great, 40,000 is excellent. A convoy of ships is better than a single ship (which makes the single giant asteroid spaceship idea a bit less desirable).
Who's going to look after the embryo children if the generational population died out, or are crippled by genetic defects?
That's why you need on-ship genetic variation. The on-ship population needs to survive, year after year, century after century.
Sure, the idea that the ship also hatches embryos en-route in case of gaps is fine, except for the catastrophe case (decimation of the population means the population is too weak or non-existent to even raise the in-ship hatchlings).
It seems that 2000 people is a strong enough population, especially if spread over several different spaceships travelling in convoy (which also helps with the Dunbar's number issue). But 150, or 500, is not enough.
Or you wait long enough until spaceships are fast enough to allow the people who want to populate another planet to be the ones who arrive there and populate it. Advances in cryogenic sleep may allow this.
figure out how to introduce additional genetic diversity once you arrive and establish yourselves.
Keeping to the spirit of the original article (i.e., ignoring embyros and overloading the workload of the colonists to also raise loads of children on the side, rather than just a few children), that could mean staggering the launch of each of the ships, rather than launching together.
By the time the second ship arrives, the crew of the first ship are either all dead (and their roles fall to the second ship), or the first ship has prepared the optimal landing site with all the facilities, cleared the lands for the orchards (which will be mature by the time the second ship arrives) and agricultural needs, and have enough information on living on the new planet to get the new colonisers up to speed rapidly.
Again, human nature is going to be a major problem. A close knit community on the ground, say for 10, or even 20 years, is probably not going to welcome the next spaceship load of humans. But they would like the tools and seeds and animals and facilities they have. There is a strong chance that instead of one large colony, you'd end up with multiple, small, separated colonies. Maybe close enough to trade and therefore amalgamate one day...
And if you don't think that 150 humans (however advanced and brilliant their on-ship education and upbringing is) aren't going to be selfish and decide that they would rather raise their own children than 10,000 "other peoples" children then you've got another thing coming. It's not like anyone is going to be able to punish them for making a decision like this either.
Disregarding that, these 150 people will be spread over a range of ages and capabilities too. So maybe there will be 50 couples capable of raising an additional child every three years, for the rest of their lives. I.e., you can probably hatch up to 20 additional children a year from the 10,000 at most. Which isn't an ideal rate, I would assume that the extra genetic diversity such a small injection provides would be lost. That's if they're not excluded from society as being "others", blah blah human nature, etc. Of course the population would increase rapidly, so the rate of hatching could increase too.
But then you need people to actually build the civilisation on the new planet. Agriculture, Buildings, Defences. I'm sure the initial landing fleet (for humans and end-of-journey world-building supplies) would suffice initially, but even so a sizeable portion of the population is going to be engaged in colonisation, not parenthood.
Maybe 2000 people + 10,000 embryos would work better. Keeping 2000 people entertained on their asteroid based spaceship is going to be fun.
Or you could read the article and get answers immediately.
They use file hashes of previous DMCA requests when new files are shared. If it transgresses, it's blocked just like this situation.
It's not "policing", it's blacklisting the sharing of specific files via comparing file's hash against a list of blacklisted hashes.
I just hope they're not using CRC16.
You would have thought that insurance companies would have been quite quick to refuse to cover the properties because of the risk. "We'll have to apply a landslide exemption to this cover" should ring alarm bells, just as "We won't cover flood damage" should be taken to mean "we expect your house to flood" because it's built on a flood plain. Yet people still buy houses on flood plains and then complain bitterly to the media when their house floods.
I don't understand why they didn't just add a "variables" CSS key.
e.g.:
div {
variables: {
color: #000000;
};
padding: 0px;
}
div.header {
color: var(color);
}
TBH I don't even think they need to be "variables", just "cascading named constants". And ultimately, because CSS hasn't supported such a feature before, even though back in the 90s people were saying how nice it would be to have such a feature, we have various pre-processors/template driven CSS/in-house solutions.
Yes, hyper-specialism is a problem, as is unwillingness to learn new things. Those Flash devs will not go far unless they push their boundaries.
SVN is not hard. Git is not hard, but a little more complex up front than svn checkout/update/commit. Any intelligent person can get their heads around these in a couple of hours, especially when someone is willing to help them or sit with them through a sample session (an essential part of mentoring).
And which framework was that? If it's targeted at "enterprise" use, then speed and efficiency won't be one of its core features, not with runtime annotation processing...
For example, Apache Wicket is a gross bloated thing to avoid the "horror" of learning how to program a web UI in JS that communicates with the backend server using sane RESTful APIs. OTOH it saves you from writing those APIs and keeps your codebase in a single object oriented language.
Hibernate is a gross-but-cool thing that saves the developer from touching JDBC. It's overhead pales in comparison with the network latency/RTT and database effort though, and it allows the programmer to again do database operations at a decent OO high level. Personally, I prefer JDBC but that can end up with a lot of boilerplate code to do simple operations. But OTOH you could end up with dodgy DB code, failure to try/catch/finally properly, etc. HQL can DIAF.
And Spring ... Spring does everything. Dependency injection is a major advantage (until you use it, you might wonder why your "EntityManager" class is not good enough), interceptors, etc. Ignore the MVC crap, that's old hat.
And tooling is another thing. Maven is essential for the Java developer today. Until I used it, I was happy with Ant and manually updating dependencies. Selenium is an essential web UI integration test tool too. Anything that makes testing, integration testing, etc, easier should be welcomed with open arms. Team-based development is a recipe for breaking code contracts in multiple places.
There are a lot of new tricks that a programmer that has stayed in a comfortable role for a long time could have missed, and find problems when looking for a new job. Luckily, a good C programmer is unlikely to be applying for Java roles, and roles are often now in the embedded marketplace where frameworks are less common over raw C with common libraries.
And there will be plenty of people that disagree with everything I've written. The joy of programming, eh?!
Vapourware is a bit harsh. There were delays, and the end result is not the miracle hardware that some people expected for $100, but they did make and ship the hardware, controllers and create an app store that had games in it. They were also up front about the Ouya hardware, and people were free to consider whether or not they thought it was good enough for a cheap small games console.
Can you use the Ouya controller with your Nexus 7? It is a standard Bluetooth controller, yeah?
The devices run Android, and thus gain from being able to play Android games.
Ouya has its own app store where games that are optimised for the Ouya are sold. By optimised, I mean more than just targeting the hardware, but also how it is used - controller on a TV, rather than touch-screen device.
As you can imagine, this can be quite hit and miss. Additionally, the Ouya hardware fell behind the market fairly quickly because of its use of a Tegra 3 which is actually quite poor in terms of graphical power. A Tegra 4 iteration should do a lot to fix this, although a Tegra K1 would be most optimal.
If Apple cared about this market, they would stick an A7 in the next Apple TV and thrash the Ouya senseless with superior hardware, and their app store and developer mindshare (everyone would optimise their iOS games for the Apple TV fairly rapidly).
...it seems likely that the ARM Architecture License the Intel acquired in the Digital takeover/litigation mess also transferred to Marvell.
I expect that you would be eligible for the subsidy for three years, or for your first degree (for long running degrees like medicine, where higher earnings afterwards would make it well worth investing up front in free education).
I also expect that the rate of tax required to fund it (and repay the initial upfront investment) would be more than 3%.
You could also target the free education at courses that are deemed valuable to the country's economic development and future - i.e., sciences, maths, engineering, rather than media studies, equine science and history of art.
Yes, this is the sort of task-oriented dedicated function blocks for video decode and encode that have been popular in GPU, ARM SoC and now x86 "APU" for quite some time.
Useless for high quality encoding, but great for standard consumer uses, quick encoding and transcoding of all those phone videos.
The PS4 probably uses VCE for its TwitchTV integration, for example.
Does Tizen support Android apps in any manner? (i.e., in a manner like BlackBerry 10 supports Android apps).
If not, the software ecosystem is going to be very poor, and kill the device.
If it does, then third-party native software is probably never going to get written.
But the model with disk drive and 128KB RAM was $1269 on its own, $1459 with DOS and a keyboard and a keyboard cord ($20!)...
To use the decent graphics modes, which used 32KB system RAM, you needed the 128KB version. The graphics interfered with the CPU when it needed memory, slowing it down.
But it had potential, but IBM probably wasn't the company to achieve it.
It's far easier to transfer the domains away from them and not run into the problem in the first place. Let them know why you are transferring the names, of course.
In addition, the credit card chargeback facility exists for a reason. Enough of them and the company's payment merchant can choose to put a block on the company's merchant account and ability to take payments.
Yeah, that sounds quite sane and achievable, and the fixture has loads of room to put the electronics.
Most people bin them, just like most people bin batteries.
But (at least in the UK) most supermarkets have battery recycling bins - it wouldn't be hard to add a CFL recycling bin to encourage recycling once they die.
If it dies after a week, then return it on your next trip to the shop, which will undoubtedly be within the warranty period of the bulb. It's the cheap electronics they put in mass produced CFLs, that's why some die early. They seem sensitive to less than ideal electricity supplies (and temperature).
The worry is that LED bulbs and CFLs share very compact electronics, and that is what dies most of the time. Hopefully the LED bulbs currently have higher quality electronics being a premium product at the moment.
Overall, the electricity savings make up for the additional cost many times over, even if the odd bulb dies too quickly.
CFLs are evil, expensive, toxic, and they don't last anywhere near as long as the packaging claims.
Nope. How can an inert thing be "evil"?
Nope. They're pretty cheap these days. Not as cheap up-front as an incandescent, but the savings in power more than make up for it.
Nope. If you're talking about the trace amount of mercury, you need to consider the mercury emitted by the power station burning coal to power your 100W dinosaur of a light.
Nope. Many people have 10, 20 year old CFLs still running.
Stop basing your opinions on cheap-ass CFLs sold by cost-cutting, quality-cutting retailers.
The problem with CFLs and LEDs is that they incorporate AC/DC electronics in every bulb. It is this that usually fails, rather than the bulb. Obviously, with electronics, it usually dies quick, if it's going to die, and you can take it back to the store for a replacement under warranty. The solution in the long term is that houses should have DC lighting circuits, and one, high quality, AC/DC convertor for all the sockets. Fine for new builds, but nobody will want to rewire, so the electronics in every bulb is here, probably for a long long time.
And yes, occasionally an incandescent can last a long time. And for all that time, it is burning 60W or 100W, rather than ~20W. And for this reason, the people who benefit most from up-front expensive bulbs are the poorest, as the ongoing running costs save far more than the up-front cost.
(In 100 years we will probably have people running 100 year old LED bulbs too).
LED light quality is surprisingly good as well. IMO more agreeable than CFL.
You can post all the facts you want, but some people will still be whining about their precious dangerous hot wasteful incandescents.
Maybe you should try an infographic version of your post.
Oh, and don't forget the lifespan of the LED bulbs. On a per-year basis, and an average of 15 years (or 25 years) lifespan, you're talking about 50 cents a year for the bulb itself - probably lower than the cost for incandescents given how frequently they fail.