You've just reinvented the revolving door, a widely known and very effective technique for funneling money from private companies to lawmakers. Congratulations--you've actually suggested a change that would make this already very bad situation even worse.
"Money out of politics instantly"...I think you seriously underestimate how much money is involved. Our lawmakers get rich via indirect payments too. Campaign funding isn't even the worst problem. That gets spent by the campaign. Personal windfalls to the lawmaker don't though, so there is a long list of those too. The circle works like this:
-Company tells Congressman they want to build a new office in an area, but it needs rezoning and better roads to the location. -Congressman purchases real estate in the area. -The road construction and rezoning are pitched and passed as something that will bring new jobs to the area. Taxpayers foot the bill. -Real estate prices along road increase, both due to improved transport there and due to the company buying up land there. -Congressman sells the land at a hefty profit.
Throw Them All Out has a 20 page chapter just on real estate deals with this basic structure. They might instead nudge the path of construction toward property they already own, but the basic flow is the same. No one step of this is illegal, and the more sophisticated politicians further mask their involvement via shell companies or relatives.
There's dozens of variations on this theme. A lot of them involve stock trades. Congress didn't even try to act like they weren't doing insider trading until last year's STOCK act. All that is happening there is that the scheme have added a level of indirection so they're less obvious.
The revolving door approach works too. Give a company some breaks while you're in office, and then they provide you a hefty salary when you return to private work. Work privately for a few years, fill your piggy bank, and then return to another public position; repeat. That one is why the SEC doesn't do anything useful about insider trading at the major trading firms. Too many of its lawyers get hired by the same companies they should be prosecuting. Would you prosecute a company that offers you a big starting bonus in a few years if you just quietly avoid investigating them today? If you don't have a problem with that, why are you reading Slashdot--you should be working on your campaign instead.
Of course you can add a prefix to each vendor and therefore allow them to share a larger bug address space. The simplest scheme is to make RedHat bugs RH-xxxxxx, Debian ones DE-xxxxxx, etc. The shared allocation approach taken by CVE numbering could be used too. I would call that a combined or aggregated stream of bug numbers rather than a single stream; that's a hair splitting distinction though.
Regardless, to be effective for tracking regular bugs and features, you would also need resources to coordinate things like tagging duplicates across vendors. A Linux bug might be upstream of ten different distribution bugs. When it's fixed in the kernel, which bug number should the commit refer to?
With a complicated enough mapping of vendor bug number to kernel bug number, you could try to capture this information too. That's another shared resource someone needs to maintain though. It's overhead with little perceived value to the individual vendors involved. Linux distributors are motivated to get bug fixes pushed upstream. There's a benefit in it for them. There's little benefit for any one vendor to having a universal bug number mapping tracker, relative to the complexity you'd need to maintain a useful one. Even if you had most of the major distributions agreeing on the shared numbering scheme, there's also time needed to coordinate the bug ids for contributions to the project outside of those vendors.
The number of CVE incidents is low enough (and the issues serious enough) that the bug id mapping they do is not a serious drag on development. One of the reasons the Linux kernel can innovate at a high rate is because it's not burdened by this sort of management issue most of the time.
Technically the US is more of a plutocracy now. The great part about using that term is that it's already tied to Nazi propaganda about jews in America, so you provide a direct path to Godwin the discussion by mentioning it.
You can't have a single stream of bug numbers in a true multi-vendor open source project. RedHat can assign something a bug number, but so can the Debian team, Canonical, etc. Seeing a unique bug number for a free software project is actually a bad sign. It usually means a single person or company is behind that project. What you want instead is a developer community that can survive losing any one member.
It costs a lot of money to get a patent and take someone to court for violating it. It isn't a game for a small business to play. The odds your small business will be sued into oblivion by a larger company asserting frivolous patents are far higher than the odds you'll sue one successfully.
I give you maybe three hours before your first complaint, that the previous customer used Photoshop to draw a background image full of penises. And a day before you're a spambot.
My prediction is that a sizable percentage of users will treat the Creative Cloud a stopgap measure, to allow them to get by until they can fully migrate away from Adobe products to a competing solution. Now would be an excellent time to short Adobe's stock. I fully expect it to go down to somewhere around $15 (just above their book value per share) in short order.
But in the short term income may go up, because people won't be able to wean themselves off of the software immediately. It will probably take over a year before lost revenue from defection even starts to overwhelm the new, steadier income flow from customers who don't have a good alternative except to upgrade. So why would the stock go down now? Sounds like definite short-term good revenue news with only a risk of terrible long-term outcome, and that's exactly the sort of thing that makes stock prices go up nowadays.
Combine that with how the stock is already priced at the top end of its range after a long period of upward movement, and you'd be a fool to short Adobe now. There's a large number of shares traded by institutional investors already owned now, and they will see this as a sound business strategy. Market prices are dominated by the herd behavior of those idiots, and they far outnumber what's traded by people who see the pending downside today. Adobe share prices could keep going up for another 5 years before the consequences of this mistake hits the price. Historically, ADBE is so strong it only crashes when the entire equities market does. And if you want to setup a short position that profits when there's a market crash, there are less risky ways to do that than to pick a stock that's in the middle of an upward breakout.
The Stac article claims "infringement by Microsoft was not willful". That's why I just linked to where people could read through the story rather than put my own spin on it. I don't use "theft" for this sort of thing because I don't like to recognize that technology protected mainly by software patents deserves to be called property. If I want to accuse Microsoft of something that's certainly true, I'd say that they're monopoly abusing criminals instead; that no one can dispute.
The performance analysis tools for PostgreSQL are still rough, but they're coming out stronger now than ever before. The old slow query profiling approach is based on database log files, and the pgbadger tool has gotten a lot of improvements in the last year to take the lead in that area. Some web app providers have added PostgreSQL data collection and visualization to the products recently, Datadog is a good example, they even run Postgres internally.
Last year's PostgreSQL 9.2 added a built-in query profiling feature via an improved pg_stat_statements module. That makes it relatively easy to see what queries are taking up time on the server, in a way that matches similar statements based on underlying their query plan. I wrote a sort of call to arms to suggest how the next generation of analysis tools can leverage that in Beyond Query Logging.
You are correct that no one has really grabbed ahold of this area and put together a really easy to use tool set around it. All of the hard to construct pieces needed are in place now, and my list of goals for this year's 9.3 development includes pushing the tuning methodology outlined in my High Performance PostgreSQL 9.0 book into some reference tool implementations. The idea that this is a "black art" is coming from consultants who want you to be intimidated. People who want to understand how things work can read my book, and then wander out to confidently build terabyte size databases. I talk with new people who have done just that every week now.
When they say that Twitter has your back, that means they cover 140 square inches of it. That's definitely not all of it though, and it doesn't even come closing to reaching where they will cover your ass.
I would speculate that there are thousands of people who have done this type of work on most popular open systems, and some of them most certainly have dozens of machines to keep up to date.
One of the large anecdote examples I was on the edge of was how the PostgreSQL project migrated infrastructure from a heavy use of FreeBSD toward Linux. I'm not quite familiar enough with FreeBSD to comment on how many of their problems were specific to the jails structure they were using. But even with the relatively good pull PostgreSQL has for finding volunteers, we were able to find exactly zero people who felt comfortable they could solve the project's issues around package management. Switching to Linux instead has vastly increased the number of people able to help.
To any extent that the BSDs can move toward binary packaging that acts more like Linux's, I think that's a good thing. ports is great for a lot of situations and you certainly can solve a variety of use cases with it. It really could be a lot easier for non-experts to use in a way that gets repeatable server builds though.
The leading edge for what compiler is used to build the system packages lags pretty far behind current, and that's not necessarily a bad thing. To put this in perspective, right now the business mainstream RHEL6 is using gcc 4.4. It's particularly easy to rebuild your whole system with a later compiler given the ports system.
Saying that something isn't a large multi-core server until it hits supercomputer scales is setting the bar a bit higher than I think most people care about. I get exposed to more leading edge hardware than most people, since I'm well known for doing database performance tuning. I see 48 core servers all the time at businesses; even my toy server at home has 24 cores nowadays. I have seen SGI Altix hardware with a very large number of cores, and most recently I had root access and some testing time on a 256 core server. I see those as pretty exceptional cases though. There's very few people who care about scaling above 48 cores right now.
Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).
It's manageable for a single system. The installations I've seen switch away from FreeBSD over this issue mainly cited how much effort it took to synchronize package sets on lots of machines at once. Let's say you kick off adding a new machine every week and need four of them. By the end, the odds are significant that the last system will not have the same setup as the first, given that three weeks have gone by. The actual compile time involved means that you can't even be assured that systems are identical even if you kick off a port update at the same time. If one machine is faster than the rest, it might end up with a different package set.
You can try to manage this with enough work and knowledge of the ports system. But that knowledge isn't very widely available. It's a whole lot easier to get a repeatable build with an easy to find Linux administrator. It's trivial to make a farm of RedHat Linux systems all have identical package sets for example. If you get official RHEL, they even provide a dashboard to help with the job.
You won't impress anyone just by committing code to github. What rightfully does impress people is when others use your code in some way. That's what the example in TFA talked about. The simplest useful metrics for github are how many people have forked your code, have "starred" your repos, or how much of your code has been merged by other people into their repos. You might game those by making a bunch of dummy accounts to grab your code. You'd have to adopt spammer style tactics against github to do it though. And it would likely be obvious to any real person who double-checked you out; at a minimum you'd have to spread the fake adoption over a long period of time to be non-obvious. It's not as if the ranking system is the only thing going into a hiring decision.
Slashdot Mirror
You've just reinvented the revolving door, a widely known and very effective technique for funneling money from private companies to lawmakers. Congratulations--you've actually suggested a change that would make this already very bad situation even worse.
"Money out of politics instantly"...I think you seriously underestimate how much money is involved. Our lawmakers get rich via indirect payments too. Campaign funding isn't even the worst problem. That gets spent by the campaign. Personal windfalls to the lawmaker don't though, so there is a long list of those too. The circle works like this:
-Company tells Congressman they want to build a new office in an area, but it needs rezoning and better roads to the location.
-Congressman purchases real estate in the area.
-The road construction and rezoning are pitched and passed as something that will bring new jobs to the area. Taxpayers foot the bill.
-Real estate prices along road increase, both due to improved transport there and due to the company buying up land there.
-Congressman sells the land at a hefty profit.
Throw Them All Out has a 20 page chapter just on real estate deals with this basic structure. They might instead nudge the path of construction toward property they already own, but the basic flow is the same. No one step of this is illegal, and the more sophisticated politicians further mask their involvement via shell companies or relatives.
There's dozens of variations on this theme. A lot of them involve stock trades. Congress didn't even try to act like they weren't doing insider trading until last year's STOCK act. All that is happening there is that the scheme have added a level of indirection so they're less obvious.
The revolving door approach works too. Give a company some breaks while you're in office, and then they provide you a hefty salary when you return to private work. Work privately for a few years, fill your piggy bank, and then return to another public position; repeat. That one is why the SEC doesn't do anything useful about insider trading at the major trading firms. Too many of its lawyers get hired by the same companies they should be prosecuting. Would you prosecute a company that offers you a big starting bonus in a few years if you just quietly avoid investigating them today? If you don't have a problem with that, why are you reading Slashdot--you should be working on your campaign instead.
Of course you can add a prefix to each vendor and therefore allow them to share a larger bug address space. The simplest scheme is to make RedHat bugs RH-xxxxxx, Debian ones DE-xxxxxx, etc. The shared allocation approach taken by CVE numbering could be used too. I would call that a combined or aggregated stream of bug numbers rather than a single stream; that's a hair splitting distinction though.
Regardless, to be effective for tracking regular bugs and features, you would also need resources to coordinate things like tagging duplicates across vendors. A Linux bug might be upstream of ten different distribution bugs. When it's fixed in the kernel, which bug number should the commit refer to?
With a complicated enough mapping of vendor bug number to kernel bug number, you could try to capture this information too. That's another shared resource someone needs to maintain though. It's overhead with little perceived value to the individual vendors involved. Linux distributors are motivated to get bug fixes pushed upstream. There's a benefit in it for them. There's little benefit for any one vendor to having a universal bug number mapping tracker, relative to the complexity you'd need to maintain a useful one. Even if you had most of the major distributions agreeing on the shared numbering scheme, there's also time needed to coordinate the bug ids for contributions to the project outside of those vendors.
The number of CVE incidents is low enough (and the issues serious enough) that the bug id mapping they do is not a serious drag on development. One of the reasons the Linux kernel can innovate at a high rate is because it's not burdened by this sort of management issue most of the time.
Technically the US is more of a plutocracy now. The great part about using that term is that it's already tied to Nazi propaganda about jews in America, so you provide a direct path to Godwin the discussion by mentioning it.
You can't have a single stream of bug numbers in a true multi-vendor open source project. RedHat can assign something a bug number, but so can the Debian team, Canonical, etc. Seeing a unique bug number for a free software project is actually a bad sign. It usually means a single person or company is behind that project. What you want instead is a developer community that can survive losing any one member.
It costs a lot of money to get a patent and take someone to court for violating it. It isn't a game for a small business to play. The odds your small business will be sued into oblivion by a larger company asserting frivolous patents are far higher than the odds you'll sue one successfully.
HAVE YOU EVER TRIED TURNING OFF THE CAPS LOCK?
(Filter error: Don't use so many caps. It's like YELLING.)
I give you maybe three hours before your first complaint, that the previous customer used Photoshop to draw a background image full of penises. And a day before you're a spambot.
My prediction is that a sizable percentage of users will treat the Creative Cloud a stopgap measure, to allow them to get by until they can fully migrate away from Adobe products to a competing solution. Now would be an excellent time to short Adobe's stock. I fully expect it to go down to somewhere around $15 (just above their book value per share) in short order.
But in the short term income may go up, because people won't be able to wean themselves off of the software immediately. It will probably take over a year before lost revenue from defection even starts to overwhelm the new, steadier income flow from customers who don't have a good alternative except to upgrade. So why would the stock go down now? Sounds like definite short-term good revenue news with only a risk of terrible long-term outcome, and that's exactly the sort of thing that makes stock prices go up nowadays.
Combine that with how the stock is already priced at the top end of its range after a long period of upward movement, and you'd be a fool to short Adobe now. There's a large number of shares traded by institutional investors already owned now, and they will see this as a sound business strategy. Market prices are dominated by the herd behavior of those idiots, and they far outnumber what's traded by people who see the pending downside today. Adobe share prices could keep going up for another 5 years before the consequences of this mistake hits the price. Historically, ADBE is so strong it only crashes when the entire equities market does. And if you want to setup a short position that profits when there's a market crash, there are less risky ways to do that than to pick a stock that's in the middle of an upward breakout.
They just need to follow the lead of the other marketing geniuses who brand free software. Coming in 2013: LibreGimp!
Never hand SAIC a check
Fixed this for you.
The Stac article claims "infringement by Microsoft was not willful". That's why I just linked to where people could read through the story rather than put my own spin on it. I don't use "theft" for this sort of thing because I don't like to recognize that technology protected mainly by software patents deserves to be called property. If I want to accuse Microsoft of something that's certainly true, I'd say that they're monopoly abusing criminals instead; that no one can dispute.
Also from that era, DOS 6.0, where the only really useful feature was later removed due to patent issues.
Let me see if I've got this right: there are people who think New Coke was a successful switch to HFCS "without public outcry"?
The performance analysis tools for PostgreSQL are still rough, but they're coming out stronger now than ever before. The old slow query profiling approach is based on database log files, and the pgbadger tool has gotten a lot of improvements in the last year to take the lead in that area. Some web app providers have added PostgreSQL data collection and visualization to the products recently, Datadog is a good example, they even run Postgres internally.
Last year's PostgreSQL 9.2 added a built-in query profiling feature via an improved pg_stat_statements module. That makes it relatively easy to see what queries are taking up time on the server, in a way that matches similar statements based on underlying their query plan. I wrote a sort of call to arms to suggest how the next generation of analysis tools can leverage that in Beyond Query Logging.
You are correct that no one has really grabbed ahold of this area and put together a really easy to use tool set around it. All of the hard to construct pieces needed are in place now, and my list of goals for this year's 9.3 development includes pushing the tuning methodology outlined in my High Performance PostgreSQL 9.0 book into some reference tool implementations. The idea that this is a "black art" is coming from consultants who want you to be intimidated. People who want to understand how things work can read my book, and then wander out to confidently build terabyte size databases. I talk with new people who have done just that every week now.
Make sure you test it against reflections in a mirror too.
When they say that Twitter has your back, that means they cover 140 square inches of it. That's definitely not all of it though, and it doesn't even come closing to reaching where they will cover your ass.
I would speculate that there are thousands of people who have done this type of work on most popular open systems, and some of them most certainly have dozens of machines to keep up to date.
One of the large anecdote examples I was on the edge of was how the PostgreSQL project migrated infrastructure from a heavy use of FreeBSD toward Linux. I'm not quite familiar enough with FreeBSD to comment on how many of their problems were specific to the jails structure they were using. But even with the relatively good pull PostgreSQL has for finding volunteers, we were able to find exactly zero people who felt comfortable they could solve the project's issues around package management. Switching to Linux instead has vastly increased the number of people able to help.
To any extent that the BSDs can move toward binary packaging that acts more like Linux's, I think that's a good thing. ports is great for a lot of situations and you certainly can solve a variety of use cases with it. It really could be a lot easier for non-experts to use in a way that gets repeatable server builds though.
The leading edge for what compiler is used to build the system packages lags pretty far behind current, and that's not necessarily a bad thing. To put this in perspective, right now the business mainstream RHEL6 is using gcc 4.4. It's particularly easy to rebuild your whole system with a later compiler given the ports system.
Saying that something isn't a large multi-core server until it hits supercomputer scales is setting the bar a bit higher than I think most people care about. I get exposed to more leading edge hardware than most people, since I'm well known for doing database performance tuning. I see 48 core servers all the time at businesses; even my toy server at home has 24 cores nowadays. I have seen SGI Altix hardware with a very large number of cores, and most recently I had root access and some testing time on a 256 core server. I see those as pretty exceptional cases though. There's very few people who care about scaling above 48 cores right now.
Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).
It's manageable for a single system. The installations I've seen switch away from FreeBSD over this issue mainly cited how much effort it took to synchronize package sets on lots of machines at once. Let's say you kick off adding a new machine every week and need four of them. By the end, the odds are significant that the last system will not have the same setup as the first, given that three weeks have gone by. The actual compile time involved means that you can't even be assured that systems are identical even if you kick off a port update at the same time. If one machine is faster than the rest, it might end up with a different package set.
You can try to manage this with enough work and knowledge of the ports system. But that knowledge isn't very widely available. It's a whole lot easier to get a repeatable build with an easy to find Linux administrator. It's trivial to make a farm of RedHat Linux systems all have identical package sets for example. If you get official RHEL, they even provide a dashboard to help with the job.
You won't impress anyone just by committing code to github. What rightfully does impress people is when others use your code in some way. That's what the example in TFA talked about. The simplest useful metrics for github are how many people have forked your code, have "starred" your repos, or how much of your code has been merged by other people into their repos. You might game those by making a bunch of dummy accounts to grab your code. You'd have to adopt spammer style tactics against github to do it though. And it would likely be obvious to any real person who double-checked you out; at a minimum you'd have to spread the fake adoption over a long period of time to be non-obvious. It's not as if the ranking system is the only thing going into a hiring decision.
See Metric System Thriving In Nation's Inner Cities for a full report.
I couldn't find /etc/mod_me_down on my machine. Is that an Ubuntu thing?
It used to be, but Canonical has replaced it with something that just reports all the moderation you do locally back to them.
TECO. In between rounds of yelling at the kids on my lawn that they don't understand what Turing complete means.