Because... of the reasons outlined in the rest of my post. Solving the problem may not be hard, but identifying the problem (as opposed to the very broad area) is.
If you're using AWS as a replacement for a dedicated machine, then you're doing it wrong. Even then, your comparison is disingenuous, because you're not costing in rack space, cooling, power, and so on in your purchase price.
The point of AWS is if you need to spin up a few (or a lot of) instances quickly and use them for short periods. How long does it take you to buy and rack that Dell system? If you can get it in under 2 days then your admin staff are incredibly impressive. If you can get it in a week, then they're doing pretty well. Amazon can get you the instance in a useable state in a few minutes. They can also dispose of the machine in a few minutes. That's a lot cheaper than buying those Dell instances to support your peak load, if you only ever hit that load once a year and are at 10% of that the rest of the time.
Judging obviousness is difficult, because most solutions are obvious if someone explains the problem well enough. One of my favourite papers describes a series of spinlock implementations, and by the time you get about half way through you've worked out what their good solution will be, but most people will not come up with that design if you tell them to design a spinlock. Even if you tell them to design a spinlock to minimise cache-coherency bus traffic, their final design isn't quite obvious, but by the time they've finished defining exactly what the requirements and limitations of the physical hardware are, then it starts to be. There are lots of similar examples, where the difficulty is not in solving the problem so much as identifying exactly what the problem that needs to be solved is. This is also a problem in a number of tech companies' hiring processes (Google is the most obvious example), where they focus so heavily on finding problem solvers that they end up with a shortage of people who are good at working out which problems are the ones that need solving.
I'd prefer that people spending my taxes thought more about the 'will work in the future' part and not just 'works now'. As in:
What happens if the supplier goes bust?
What happens if the supplier decides to stop supporting the software?
What happens when our requirements change and we need an extra feature?
Unless the purchased software comes with the right for the customer to create (and use and duplicate) derived works, all of these questions are difficult to answer. And if it does come with those rights, then it most likely meets the definition of open source.
A big part of the problem with local government software procurement is that every local authority spends money getting a company to develop (mostly from scratch) a system that almost suits their needs. These needs are typically almost identical to the needs of every other local authority. They could safe a huge amount of money if they'd collaborate on the common elements and just extend a shared codebase to meet their requirements.
It's important not to conflate 'open source' and 'community developed' in this situation. A requirement that all procurements be open source just means that, as part of the purchase, the government gets a perpetual license that permits modification and redistribution (both of the original and derived works). It can still be bespoke software written by Oracle or IBM (or in-house), or a completely off-the-shelf product, but the customer is then always able to find a second source for maintenance if one is required.
Looks like some special interests are trying to strike another blow against people actually owning the movies that they buy
I'd read this another way: it's a measure of the environmental impact of DRM. If you could stream DRM-free video then you could play it on any device, or buffer it to an arbitrary degree. There would be little reason to use DVDs in any locale where you had a moderately competent Internet connection (you could download the movie overnight if you didn't have a fast enough connection to stream).
You don't get to watch the disc again, or lend it to a friend. And if you do watch it again on-line, you can completely ignore any costs involved
The more important comparison is streaming with DVD rentals by post. If you want to watch a DVD a second time, then the rental company will post it to you again. The number of DVDs that are rented by post because either the studios won't make certain things available for streaming, or the DRM prevents people from playing them back in their player of choice is huge.
The cost of formal verification has dropped a lot over the last few years, but it's still a couple of orders of magnitude more expensive than a good testing regime. You also run into issues with Goedel's incompleteness theorem: you can't write a specification of a program that accounts for all possible bugs that is less complex than the program itself, and so it is often harder to write a bug-free specification than to write a bug-free program.
This is the case for the multicompiler. It uses the -frandom-seed argument that is already used by gcc and clang to seed various other nondeterministic processes. This sentence in the summary annoyed me a lot:
although the article doesn't provide examples of what kinds of diversity are possible whilst maintaining the program logic, nor what kind of attacks would be prevented with this approach."
I don't know if TFA actually didn't, but the UCI group has published some papers on the multicompiler work, including this one from CGO last year. The main goal for this is to provide defence against return-oriented programming (ROP) attacks, where you chain together 'gadgets' (small chunks of code that do a little bit of computation and then return). One of the things that they do is insert NOPs to reduce the number of gadgets. This is an x86-specific thing, because the variable-length instructions mean that a single binary sequence can be several different instruction sequences depending on the byte offset where you start reading it. They also try to ensure that gadgets are in different places in every program build. This means that a ROP exploit has to be tailored to the target - you can't just have one byte string that, when pushed onto the stack, will exploit everyone.
Oh, and for anyone who says 'ASLR solves this!', take a look at the Blind ROP paper from Stanford.
We're currently investigating incorporating the multicompiler into the FreeBSD package build infrastructure.
The problem with unions in the US is lack of competition. In most of the rest of the world that has had a labour movement, you have a choice of which union you wish to join (or not joining one at all). There are also often legal protections preventing paying union members more than non-union employees so that the collective bargaining by the union benefits everyone (although if they have fewer members then their possible threat of strike action doesn't do much). In the USA, it's very common to have a single union that can represent you - your choice is either to join that union (and be screwed by union management that is only out for itself) or not join and be screwed even more by the company because you're not part of the collective bargaining. When unions have to compete with each other for membership, then they have a strong incentive to at least be seen to represent their members.
Near-field communication: wave the things you've bought against the control box before you install them. Or have a wand (or wand app in your phone) that you wave at them to activate them. If they haven't been tagged like this, they refuse to accept any connections. Seriously, not all UI problems are impossible to solve.
With encryption without authentication, many people will assume they gain some security when they are not
The do gain some security. They gain security against passive adversaries. They don't gain security against adversaries who are able to intercept and modify their traffic. The question is whether the first threat model is a sensible one to care about. Given that we now know that there is at least one global passive adversary (and likely others who didn't have a Snowden), it seems sensible to me.
Also, it has higher overhead and higher implementation complexity, increasing cost both for the implementation and the platform it runs on (thing small embedded devices, e.g., that can do (very basic) http even on small 8 bit controllers, but forget about fitting any crypto on the
Most IoT platforms are looking at using the ARM Cortex-M0 (or M0+) as the client devices. At the data rates required for IoT tasks, this can easily keep up with the demands of modern crypto. If it can't, then an accelerator is only a few thousand extra transistors for your SoC.
Within my house, I'd expect the certificates to be issued by the control system and I'd expect two-way validation: no one can talk to my lightbulbs unless they have a client certificate issued by my house control system CA. Oh, and I also wouldn't expect to use HTTP...
Not sure about the USA, but veterinary graduates in the UK have the highest suicide rate of any discipline. It turns out that most people who go into the subject do so because they like animals, and much of the job of a qualified vey (especially a newly qualified vet) involves killing animals. With that in mind, a career in IT doesn't sound so bad.
Here, by the way, the veterinary school has the most unbalanced gender ratio of any department in the university (more so than computer science), but (as you say) it's female dominated. I suspect that the reason this is seen as of less concern is that our society is increasingly dependent on computers and decreasingly dependent on animals.
I don't believe that an uneven gender ratio is necessarily a bad thing, but I do mind that we're not getting the best students in computer science, and when only around 10% of our applicants are female then it looks like there's a good chance that we're missing some very competent people.
That's because car manufacturers design their cars to meet the standards where they expect to sell them. For a country that has cars as such a strong part of its national identity, the state of most US cars is astonishing. The improvements in production line reliability mean that they can make cars that are above the standards required for sale in the USA, but only by a small margin. They no longer need to add large tolerances to the design stage to make sure that all of the vehicles coming of the production line meet the standards. The flip side of this is that, although all of them are above the required standards, they are only just above, by the smallest margin that the factory can manage (any more and it costs more). If you test them to higher standards, you'd expect them to fail.
Funny, because every BeOS developer I have ever talked to has said the opposite, that BeOS is a joy to code in.
Steve Jobs wasn't the only reason Apple decided to buy NeXT for ten times what Be was asking. The BeOS APIs were easy to use to write simple applications, but they had a sudden difficulty cliff. Your GUI application was a distributed system and most of the time this was fine because the parts were independent and events arrived at low enough rates that the user wouldn't notice if they were handled in the wrong order. Once you started getting complex MVC applications, the synchronisation requirements became painful and non-obvious. In contrast, the OpenStep APIs (rebranded by Apple as Cocoa) encouraged doing everything on the main thread, which increased latency for the UI but provided a much simpler programmer model because everything happened synchronously, unless you explicitly spawned a background thread for some long-running task.
And I can tell you right now that throughput was no problem. I ran Quake II, used Gobe Productive and have done realtime video editing without any throughput issues. In fact, BeOS is still used in a number of professional studios, specifically for video and audio editing.
You're arguing that throughput isn't a problem by listing a load of latency-sensitive applications?
Basically, you don't have a clue. You're talking about something you have never even used.
I remember BeOS 5 well. I remember the TCP/IP stack that could just about manage 30 minutes of consecutive uptime on a good day (good thing it was a microkernel and you could restart the network stack). I remember that the sound subsystem crashed at least once a day. I remember applications suddenly hitting race conditions under load and exhibiting very strange behaviour.
I also fondly remember BFS and the tracker, but I don't have such a rose-tinted view of the system as some people.
Honda went through the same cycle as most Japanese companies in the second half of the 20th century. They started off producing copies of western designs. Then they started applying the traditional Japanese ingrained OCD to their QA process and began producing copies of western designs with much less quality variation. Then they started producing original designs, initially just as small improvements on western designs, then as complete redesigns. Meanwhile, most US manufacturers had fairly bad QA processes and just worked around it by putting huge tolerances into their designs so even something 15% underspec was still fine.
The problem for Tata and other Indian and Chinese companies is that the rest of the world - particularly with robotic manufacturing - has tightened up QA considerably since the times Honda could produce better copies of American designs by simply paying more attention during assembly. Cutting the budget was a big incentive for this: if you're having to overengineer everything then you're spending more on materials (and assembly) than your Japanese (or Korean) competitors and so you're unable to sell for the same price. There aren't such big wins available anymore. On top of that, neither culture has the strong tradition of attention to detail that helped the Japanese leap to the front in manufacturing.
Linux is hardly a sensible point of comparison, because the reliance on userspace sound daemons (low-latency in-kernel sound mixing would bloat the kernel, but a web server in the kernel is fine...) means that you end up needing a lot of round trips to get audio out. On FreeBSD, for example, the mixing happens in the kernel so if you really need low latency you can pin a process to a dedicated core and have it pushing things out very quickly. Most of the time, it's fine to keep the buffers filled and allow other processes to share the core.
Fear of failure is the biggest obstacle to getting good results. If you can afford it, then having 10 teams go off and do things that will probably fail is a good way of finding the one path that has unexpected good results. The Haiku team isn't costing anyone anything (and their code is permissively licensed, so occasionally interesting bits end up in other systems). Even if it's a dead end, it's worth having someone check that it doesn't go anywhere - you never know, there might be some useful spin-offs.
Please let me know where you work as a hardware designer so that I can make sure never to buy your company's products. There is a cycle between specialised and general purpose compute that has been through about half a dozen complete oscillations. If you're only aware of it moving in one direction, then you're not much of an enthusiast either - especially as you have it moving in the wrong direction.
If you want some further reading, look up 'dark silicon'. Transistors are still getting smaller and cheaper, but they're no longer consuming significantly less power each generation. This means that it's increasingly cheap to put things on a die, but expensive to actually have them turned on at any given time. For most efficient die usage, you want to have most of your chip covered in accelerators for particular workloads that are powered down 90% of the time but provide significant performance increases when used.
There's nothing pure or noble about running code that is data-parallel, has little locality of reference, few branches, and predictable memory accesses on a processor that is optimised for sequential code that has a branch roughly every 7 instructions on average, has strong locality of reference, and relies on smallish working sets for good performance (the CPU) when there's a processor with a high-throughput streaming memory interface designed for branch-light workloads with lots of parallel cores (the GPU). It's just inefficient use of resources.
The GUI toolkit made aggressive use of threading. This was good for latency, but not great for throughput because you ended up doing a lot of context switching. It was also quite hard to program, because you had to be very careful about synchonisation.
The problem with the full pints campaign was that it introduced bigger glasses with a pint line a bit from the top, and people felt ripped off if the beer plus the head didn't go all of the way to the top of the glass. A number of surveys showed that people thought that they got more beer when they got a smaller glass that was completely full than a slightly larger one with a small gap at the top.
It's not quite that simple. You're hired to top academic positions based on research output and the top universities tend to encourage people to submit work to top-tier publication venus. They also have a lot of people around who have submitted work to these places and can help junior academics / PhD students aim their work at the places where it's most likely to be accepted. People from second-tier universities tend to send work to second-tier conferences and journals, even when it's work that could have got in to a top venue. If they'd sent it somewhere better, it would be more likely to be cited, which would bump up their impact scores when applying for a senior position.
1) Non-person entities cannot donate directly to any candidate or cause, but rather must fund their own "campaigns". If say ATT or Google want to help elect people, they can buy their own damn TV spots. "Google supports Harry Reid for senate".
Here's a simpler one: since it's already illegal for foreign individuals to fund US politicians, how about extending the rule to multinational corporations. Unless your company, all employees, and all assets are based in the USA then you don't get to influence the election. If you meet all of these criteria, then you're just an association of people who are eligible to vote, so go ahead.
a brand new party brought to power due entirely to the population's displeasure with the previous party will realize that they had better mind their Ps and Qs least they go out just as fast as they came in.
That's assuming that it's a new party, and not just a new member of the existing party. Why would you care that you'd be voted out in the next election if you already had some cushy directorships lined up thanks to your work in the current term?
Slashdot Mirror
Because... of the reasons outlined in the rest of my post. Solving the problem may not be hard, but identifying the problem (as opposed to the very broad area) is.
That's the second time today you've been moderated up for a highly misleading explanation of Schroedinger's cat.
If you're using AWS as a replacement for a dedicated machine, then you're doing it wrong. Even then, your comparison is disingenuous, because you're not costing in rack space, cooling, power, and so on in your purchase price.
The point of AWS is if you need to spin up a few (or a lot of) instances quickly and use them for short periods. How long does it take you to buy and rack that Dell system? If you can get it in under 2 days then your admin staff are incredibly impressive. If you can get it in a week, then they're doing pretty well. Amazon can get you the instance in a useable state in a few minutes. They can also dispose of the machine in a few minutes. That's a lot cheaper than buying those Dell instances to support your peak load, if you only ever hit that load once a year and are at 10% of that the rest of the time.
Judging obviousness is difficult, because most solutions are obvious if someone explains the problem well enough. One of my favourite papers describes a series of spinlock implementations, and by the time you get about half way through you've worked out what their good solution will be, but most people will not come up with that design if you tell them to design a spinlock. Even if you tell them to design a spinlock to minimise cache-coherency bus traffic, their final design isn't quite obvious, but by the time they've finished defining exactly what the requirements and limitations of the physical hardware are, then it starts to be. There are lots of similar examples, where the difficulty is not in solving the problem so much as identifying exactly what the problem that needs to be solved is. This is also a problem in a number of tech companies' hiring processes (Google is the most obvious example), where they focus so heavily on finding problem solvers that they end up with a shortage of people who are good at working out which problems are the ones that need solving.
Unless the purchased software comes with the right for the customer to create (and use and duplicate) derived works, all of these questions are difficult to answer. And if it does come with those rights, then it most likely meets the definition of open source.
A big part of the problem with local government software procurement is that every local authority spends money getting a company to develop (mostly from scratch) a system that almost suits their needs. These needs are typically almost identical to the needs of every other local authority. They could safe a huge amount of money if they'd collaborate on the common elements and just extend a shared codebase to meet their requirements.
It's important not to conflate 'open source' and 'community developed' in this situation. A requirement that all procurements be open source just means that, as part of the purchase, the government gets a perpetual license that permits modification and redistribution (both of the original and derived works). It can still be bespoke software written by Oracle or IBM (or in-house), or a completely off-the-shelf product, but the customer is then always able to find a second source for maintenance if one is required.
Looks like some special interests are trying to strike another blow against people actually owning the movies that they buy
I'd read this another way: it's a measure of the environmental impact of DRM. If you could stream DRM-free video then you could play it on any device, or buffer it to an arbitrary degree. There would be little reason to use DVDs in any locale where you had a moderately competent Internet connection (you could download the movie overnight if you didn't have a fast enough connection to stream).
You don't get to watch the disc again, or lend it to a friend. And if you do watch it again on-line, you can completely ignore any costs involved
The more important comparison is streaming with DVD rentals by post. If you want to watch a DVD a second time, then the rental company will post it to you again. The number of DVDs that are rented by post because either the studios won't make certain things available for streaming, or the DRM prevents people from playing them back in their player of choice is huge.
The cost of formal verification has dropped a lot over the last few years, but it's still a couple of orders of magnitude more expensive than a good testing regime. You also run into issues with Goedel's incompleteness theorem: you can't write a specification of a program that accounts for all possible bugs that is less complex than the program itself, and so it is often harder to write a bug-free specification than to write a bug-free program.
although the article doesn't provide examples of what kinds of diversity are possible whilst maintaining the program logic, nor what kind of attacks would be prevented with this approach."
I don't know if TFA actually didn't, but the UCI group has published some papers on the multicompiler work, including this one from CGO last year. The main goal for this is to provide defence against return-oriented programming (ROP) attacks, where you chain together 'gadgets' (small chunks of code that do a little bit of computation and then return). One of the things that they do is insert NOPs to reduce the number of gadgets. This is an x86-specific thing, because the variable-length instructions mean that a single binary sequence can be several different instruction sequences depending on the byte offset where you start reading it. They also try to ensure that gadgets are in different places in every program build. This means that a ROP exploit has to be tailored to the target - you can't just have one byte string that, when pushed onto the stack, will exploit everyone.
Oh, and for anyone who says 'ASLR solves this!', take a look at the Blind ROP paper from Stanford.
We're currently investigating incorporating the multicompiler into the FreeBSD package build infrastructure.
The problem with unions in the US is lack of competition. In most of the rest of the world that has had a labour movement, you have a choice of which union you wish to join (or not joining one at all). There are also often legal protections preventing paying union members more than non-union employees so that the collective bargaining by the union benefits everyone (although if they have fewer members then their possible threat of strike action doesn't do much). In the USA, it's very common to have a single union that can represent you - your choice is either to join that union (and be screwed by union management that is only out for itself) or not join and be screwed even more by the company because you're not part of the collective bargaining. When unions have to compete with each other for membership, then they have a strong incentive to at least be seen to represent their members.
Near-field communication: wave the things you've bought against the control box before you install them. Or have a wand (or wand app in your phone) that you wave at them to activate them. If they haven't been tagged like this, they refuse to accept any connections. Seriously, not all UI problems are impossible to solve.
With encryption without authentication, many people will assume they gain some security when they are not
The do gain some security. They gain security against passive adversaries. They don't gain security against adversaries who are able to intercept and modify their traffic. The question is whether the first threat model is a sensible one to care about. Given that we now know that there is at least one global passive adversary (and likely others who didn't have a Snowden), it seems sensible to me.
Also, it has higher overhead and higher implementation complexity, increasing cost both for the implementation and the platform it runs on (thing small embedded devices, e.g., that can do (very basic) http even on small 8 bit controllers, but forget about fitting any crypto on the
Most IoT platforms are looking at using the ARM Cortex-M0 (or M0+) as the client devices. At the data rates required for IoT tasks, this can easily keep up with the demands of modern crypto. If it can't, then an accelerator is only a few thousand extra transistors for your SoC.
Within my house, I'd expect the certificates to be issued by the control system and I'd expect two-way validation: no one can talk to my lightbulbs unless they have a client certificate issued by my house control system CA. Oh, and I also wouldn't expect to use HTTP...
Not sure about the USA, but veterinary graduates in the UK have the highest suicide rate of any discipline. It turns out that most people who go into the subject do so because they like animals, and much of the job of a qualified vey (especially a newly qualified vet) involves killing animals. With that in mind, a career in IT doesn't sound so bad.
Here, by the way, the veterinary school has the most unbalanced gender ratio of any department in the university (more so than computer science), but (as you say) it's female dominated. I suspect that the reason this is seen as of less concern is that our society is increasingly dependent on computers and decreasingly dependent on animals.
I don't believe that an uneven gender ratio is necessarily a bad thing, but I do mind that we're not getting the best students in computer science, and when only around 10% of our applicants are female then it looks like there's a good chance that we're missing some very competent people.
That's because car manufacturers design their cars to meet the standards where they expect to sell them. For a country that has cars as such a strong part of its national identity, the state of most US cars is astonishing. The improvements in production line reliability mean that they can make cars that are above the standards required for sale in the USA, but only by a small margin. They no longer need to add large tolerances to the design stage to make sure that all of the vehicles coming of the production line meet the standards. The flip side of this is that, although all of them are above the required standards, they are only just above, by the smallest margin that the factory can manage (any more and it costs more). If you test them to higher standards, you'd expect them to fail.
Funny, because every BeOS developer I have ever talked to has said the opposite, that BeOS is a joy to code in.
Steve Jobs wasn't the only reason Apple decided to buy NeXT for ten times what Be was asking. The BeOS APIs were easy to use to write simple applications, but they had a sudden difficulty cliff. Your GUI application was a distributed system and most of the time this was fine because the parts were independent and events arrived at low enough rates that the user wouldn't notice if they were handled in the wrong order. Once you started getting complex MVC applications, the synchronisation requirements became painful and non-obvious. In contrast, the OpenStep APIs (rebranded by Apple as Cocoa) encouraged doing everything on the main thread, which increased latency for the UI but provided a much simpler programmer model because everything happened synchronously, unless you explicitly spawned a background thread for some long-running task.
And I can tell you right now that throughput was no problem. I ran Quake II, used Gobe Productive and have done realtime video editing without any throughput issues. In fact, BeOS is still used in a number of professional studios, specifically for video and audio editing.
You're arguing that throughput isn't a problem by listing a load of latency-sensitive applications?
Basically, you don't have a clue. You're talking about something you have never even used.
I remember BeOS 5 well. I remember the TCP/IP stack that could just about manage 30 minutes of consecutive uptime on a good day (good thing it was a microkernel and you could restart the network stack). I remember that the sound subsystem crashed at least once a day. I remember applications suddenly hitting race conditions under load and exhibiting very strange behaviour.
I also fondly remember BFS and the tracker, but I don't have such a rose-tinted view of the system as some people.
Honda went through the same cycle as most Japanese companies in the second half of the 20th century. They started off producing copies of western designs. Then they started applying the traditional Japanese ingrained OCD to their QA process and began producing copies of western designs with much less quality variation. Then they started producing original designs, initially just as small improvements on western designs, then as complete redesigns. Meanwhile, most US manufacturers had fairly bad QA processes and just worked around it by putting huge tolerances into their designs so even something 15% underspec was still fine.
The problem for Tata and other Indian and Chinese companies is that the rest of the world - particularly with robotic manufacturing - has tightened up QA considerably since the times Honda could produce better copies of American designs by simply paying more attention during assembly. Cutting the budget was a big incentive for this: if you're having to overengineer everything then you're spending more on materials (and assembly) than your Japanese (or Korean) competitors and so you're unable to sell for the same price. There aren't such big wins available anymore. On top of that, neither culture has the strong tradition of attention to detail that helped the Japanese leap to the front in manufacturing.
Linux is hardly a sensible point of comparison, because the reliance on userspace sound daemons (low-latency in-kernel sound mixing would bloat the kernel, but a web server in the kernel is fine...) means that you end up needing a lot of round trips to get audio out. On FreeBSD, for example, the mixing happens in the kernel so if you really need low latency you can pin a process to a dedicated core and have it pushing things out very quickly. Most of the time, it's fine to keep the buffers filled and allow other processes to share the core.
Fear of failure is the biggest obstacle to getting good results. If you can afford it, then having 10 teams go off and do things that will probably fail is a good way of finding the one path that has unexpected good results. The Haiku team isn't costing anyone anything (and their code is permissively licensed, so occasionally interesting bits end up in other systems). Even if it's a dead end, it's worth having someone check that it doesn't go anywhere - you never know, there might be some useful spin-offs.
Please let me know where you work as a hardware designer so that I can make sure never to buy your company's products. There is a cycle between specialised and general purpose compute that has been through about half a dozen complete oscillations. If you're only aware of it moving in one direction, then you're not much of an enthusiast either - especially as you have it moving in the wrong direction.
If you want some further reading, look up 'dark silicon'. Transistors are still getting smaller and cheaper, but they're no longer consuming significantly less power each generation. This means that it's increasingly cheap to put things on a die, but expensive to actually have them turned on at any given time. For most efficient die usage, you want to have most of your chip covered in accelerators for particular workloads that are powered down 90% of the time but provide significant performance increases when used.
There's nothing pure or noble about running code that is data-parallel, has little locality of reference, few branches, and predictable memory accesses on a processor that is optimised for sequential code that has a branch roughly every 7 instructions on average, has strong locality of reference, and relies on smallish working sets for good performance (the CPU) when there's a processor with a high-throughput streaming memory interface designed for branch-light workloads with lots of parallel cores (the GPU). It's just inefficient use of resources.
The GUI toolkit made aggressive use of threading. This was good for latency, but not great for throughput because you ended up doing a lot of context switching. It was also quite hard to program, because you had to be very careful about synchonisation.
The problem with the full pints campaign was that it introduced bigger glasses with a pint line a bit from the top, and people felt ripped off if the beer plus the head didn't go all of the way to the top of the glass. A number of surveys showed that people thought that they got more beer when they got a smaller glass that was completely full than a slightly larger one with a small gap at the top.
It's not quite that simple. You're hired to top academic positions based on research output and the top universities tend to encourage people to submit work to top-tier publication venus. They also have a lot of people around who have submitted work to these places and can help junior academics / PhD students aim their work at the places where it's most likely to be accepted. People from second-tier universities tend to send work to second-tier conferences and journals, even when it's work that could have got in to a top venue. If they'd sent it somewhere better, it would be more likely to be cited, which would bump up their impact scores when applying for a senior position.
1) Non-person entities cannot donate directly to any candidate or cause, but rather must fund their own "campaigns". If say ATT or Google want to help elect people, they can buy their own damn TV spots. "Google supports Harry Reid for senate".
Here's a simpler one: since it's already illegal for foreign individuals to fund US politicians, how about extending the rule to multinational corporations. Unless your company, all employees, and all assets are based in the USA then you don't get to influence the election. If you meet all of these criteria, then you're just an association of people who are eligible to vote, so go ahead.
a brand new party brought to power due entirely to the population's displeasure with the previous party will realize that they had better mind their Ps and Qs least they go out just as fast as they came in.
That's assuming that it's a new party, and not just a new member of the existing party. Why would you care that you'd be voted out in the next election if you already had some cushy directorships lined up thanks to your work in the current term?