Or that high end gamers who can't get the $1000+ cards realize that they can stay with their current cards, or go with cheaper cards.

Game studios will also start to optimize their graphics more and not rely on Nvidia and AMD to save their asses for having a poorly optimized game. This will lower demand for the high end cards, because they aren't needed to get stunning graphics.

Nvidia probably realizes this and don't want to start back at square one with their marketing program, to convince gamers they need $1000+ cards, and to convince game studios that there will be enough cards out there to be lazy with their optimizations.

And once game studios learn to optimize their graphics, they'll realize that there is a much broader market out there they can service, and this will lower demand for those super high end cards, and maybe even for the $300+ cards too.

When the cryptocurrency bubble pops, they want the demand for the high and higher end cards to still be there, and it might not be if the bubble lasts too long because gamers have learned to settle, and game companies have learned to optimize better.

Not exactly getting something for nothing. The energy to turn those blades have to come from somewhere.

It will come from slowing down the air that passes by the blades, while its not a quantum butterfly effect, there will still be some sort of effect caused from pulling energy out of the air.

One turbine won't cause anything measurable, 1000 probably not as well. 1,000,000 you might see something. The effect might be something like a mountain, and cause a down draft convection effect on the downwind side of a turbine farm. Who knows maybe we can use large wind farms for both energy and weather control.

No matter what the air leaving the turbine farm will have less energy than the air going in, which will cause a pressure difference between the air above and air below, a pressure difference before the farm and after. Maybe it will be a quantum butterfly after all.
 

I opted out to all the messages except the weather alerts. I live in Phoenix, and alerts that there is a dust storm coming in is personally important. It will modify my behavior:
* Am I going to go out grocery shopping, or to a restaurant now, or wait till it blows through?
* I need to shut off the fresh air intake in the house, and make sure all the doors and windows are closed.
* Time to break out the beverage of choice and watch the wall of dust roll over the fields.

Things like that. Those alerts are important since they are personally important to the people they're being sent to. Amber/Silver alerts aren't so important: 'Look out for this Vehicle' 'but I'm at work/home/etc right now.' And when people get on the road they forget what they're suppose to be looking for. So I agree, most of those alerts are useless alerts for people who don't care. But like most cases of generalizations arguments there are exceptions.

Not only that, there were extreme safety concerns too. It use to be said that you could tell how long a brakeman had been working for the railroad by how many fingers he had left. If he had all of them he was a rookie.

Brakemen use to have to couple the cars together. Even though there were the same sort of couplers that are used today back then the railroads thought it was cheaper to use the old method. The brakeman held a loop of steel between the two cars as they were pushed together and then pulled his hand back at the last second. Then two pins were hammered into place in the couplers to hold the steel loop in place and the cars together. If there were a fraction of a second too slow getting their hands out of the way they lost fingers. The railway unions helped force the railways to go to the then patented automatic couplers. (https://en.wikipedia.org/wiki/Railway_coupling#Link_and_pin).

Brakes on the cars were also controlled by those big wheels you see at the top of the cars in the old photos. Going around a corner the brakemen had to apply the brakes to the cars to make sure they didn't derail. And there were never enough brakemen for every car on the train, so they would have to jump between cars on the moving train to apply and release the brakes. Again there was a then patented invention that used air pressure from the engine to trigger the brakes on the cars, again the companies didn't care about human life and focused on profit. The railway unions helped fix that.

The brakemen also had to often run ahead of the train to do the switching. Since switching was another one of those things that could have been automated but didn't. Trains were suppose to stop so that the switching could be done in time and the brakemen get back aboard, but time is money and you know what that means.

There's a reason that the railway owners were called robber barons. And there were a lot of things they did that we would object to, that unions helped to fix.

I am in no way saying that unions are pure and benevolent organizations. Often they're corrupt, and as greedy as the people running the corporations. They have their place, and there are a lot of instances in the 2010s that they should come back. The Amazon story is a good example of it. Uber is another good example. A lot of other areas in high tech could use them too. All of these aren't for wages as the parent to the post said, but for working conditions and safety. When there is too much power in the hands of the employers the employees suffer, and there needs to be a balance.

In absolute terms its there. Say I have a 100 Mbit pipe, and 200 providers shoving data down it equally.

That works out to 0.5 Mbits for all the providers.

Now say 10 of those providers gets 'faster lanes' at double the priority of the other 190. Those 190 providers will now only have a speed of around 0.476 Mbits, while the paying providers get 0.952 mbits. While it doesn't seem like much only a 4.8% decrease in speed for 190 providers, its still a decrease in speed.

Of course these numbers are picked to make calculations easy, it does show that with a capped resource like a cable, that 'Same Speed' providers will get less if you're giving more to others.

You also have to structure the commission right. I worked for a company that bought another company that had just straight gross commission for the the sales people. That company was losing money which is why they were bought. It turned out a lot of the problems were caused by that commission structure, where the sales people did everything to get the sale together, including marking the product down so that it was sold at a loss and offering free support. They didn't care about the profitability of the company, only their own bottom line.

If you structure the commission based on the profit on a deal then the sales people will only push the high profit margin products and newer products that are still working off their R&D costs get neglected and may never become profitable.

While I agree you have to provide commission to encourage your sales force, you have to do it in such a way that is of value to the company. Ideally it would be of value to the customer too, but Wells Fargo proved that isn't usual.

It really depends on where you work. I'm over 40 and my time on the job has been increasing as I go along
- first job was 6 weeks (company closed)
- second job was 20 months (got fed up with trying to work in the system and got a better offer).
- third job was three years (split between two companies the second one died off)
- forth job was four years (got a better job and didn't want to do on-site support in the jungles of Guyana)
- fifth job was six and a half years. (left because they gave my company vital function to experts in the field: 2 new grads in China).
- Current job is going on 4 years, don't plan on leaving it till I retire

I'm one of the newest people in my group too. Most people have been there at least 8 years, some at 15+ years. At 42 I'm in the middle of the pack when it comes to age too (we did recently get a bunch of young wippersnappers in their 30s). It is still software engineering. Though I do pay price of it not being very dynamic and bleeding edge it is stable.

As I and others have said its all depends on where you work. Some places are very unstable, others are stable.

Hey that's easy for them to fix. Just throw in an if statement that if the number of digits is two automatically put a 0 in there at the end. Problem solved that'll be 10 hours charged to your account.

Then you'll test it against $9.00. Which will turn into 9 cents. Well that's easy to fix, if the number of digits equals to one then add two zeros. Problem solved this is a bit harder, that's 15 hours charged to your account.

That covers all the problems, ship it.

Well what about a $1000.00 item? That's going to take more analysis they'll get back to you on that. And the result will be an if statement that looks up the magic number/hard coded item id, and put in the magic number / hard coded price. That'll work.

You can probably tell I've had to deal with this too often, and I'm not allowed to talk to people in India directly, I have to go through two layers of managers, and before the developers in India get told about the issues its been filtered down to just the issue, all suggested solutions have been stripped from the communications, because I was insulting their intelligence.

I just wrote some grammars for a language and I might be a bit sensitive to the way it is set up. I agree that the truckers are wrong. Looking at it from a lexical/parser perspective we have the sentence:

The canning, processing, preserving, freezing, drying, marketing, storing, packing for shipment or distribution of:

With the lexical tokens:

The (1 - article) | canning (2 - identifier) | , (3 - separator)| processing (2 - identifier)| , (3 - separator) | , freezing (2) |, (3) | drying (2) | , (3) | marketing (2) | , (3) | storing (2) | , (3) | packing for shipment (2) | or (4 - operator) | distribution of (2)

In English this would be a logical list. And that is usually set up as:

logicalList : identifierList OR_OPERATOR identifier
                              | identifierList AND_OPERATOR identifier
                              ;

identifierList : identifier
                                    | identifierList COMMA identifier
                                    ;

Long story short the OR in the wording above is the operator to tell the parser (human), what type of list it is. In this case the OR operator indicates that the list is one of the items in the list. If the last identifier was 'packing for shipment or distribution of' then there is no way to say what type of list it is.

I also think this bullshit that people can get forced to work unpaid overtime. That includes C level executives. If you're going to work the hours you should be paid for it. The only time I would disagree with this is if you signed a very specific contract that says 'I will get X, Y and Z done by T and I will be paid $ for the work' that was properly negotiated then I can see overtime needing to uncompensated. But that's for very specific mostly deterministic tasks. Driving a truck to make deliveries doesn't fall under this, there's too many uncontrolled variables (Traffic, people receiving being slow, etc).

I've worked for similar companies. The one I worked for had terrible rules.

- Passwords need to be changed every month
- Must be a minimum of 8 characters long
- Must have a mix of upper and lower case. Must have digits (more than one), and symbols
- Cannot have more than 3 characters in the same sequence as the last 12 passwords.

They did have people from HR go around and look for the sticky notes on monitors and remove them, of course writing down who was violating policy. So we just started to hide the sticky notes in our log books. And this was for a start up that was spun off of a large company that ultimately failed. Had no government, financial or similar contracts. The idiot who came up with these policies was fired 3 months later when everyone threatened to quit, what really did it was his stupid 8am - 6pm core business hour policy.

This seems to be very common at Amazon. Going by the FACE site, it shows a clear pattern of abuse, and I'm not surprised that this hasn't happened before.

Granted the FACE site is posted to those who are usually pissed at Amazon, but with so many postings and so often it shows that there is a clear pattern of employee abuse.

Even if their code was open source, you still can't trust them. Especially if the people rigging the machines is the people who own the machines.

Who is going to be able to verify all the lines of code? Even if you had a million programmers looking at it, something will probably still slip through, after all there are contests every year on making code that looks legit but is actually nefarious.

Who makes the compiler? Can you trust them? Has the code for the compiler been checked into? There's a legend (real or not) that when AT&T was going to commercialize UNIX that they asked the programmers if there were any obvious security holes. Dennis Ritchie spoke up about a backdoor he made in the C compiler. If it noticed it was creating the login program that it would automatically insert code for his username and password so that he'd always have root access. This was not in the login code, but the compiler itself. So you can't trust the compiler.

Are you using signed binaries? Well who signs the binaries and calculates the hash (see the point about the compiler).

What about what downloads the code to the voting machine? Can you trust that?

And that's just the voting machine itself, what about the thing that collects all the results from the voting machines and gives you the final results? Who's checked all that? Do you trust the people doing that? Do all the interested parties trust that?

There are so many points of failure and compromise with this that its scary. Especially when they want to go paperless, with no paper backup, and trusting it all to the machines. Some electronic voting machines are still this way.

The only voting machines that I see being any close to secure are the ones with the cardstock ballot that the voter fills in a line with a black marker to indicate who they are voting for. That can be machine counted for quick results. But to certify the election each ballot should be counted by a human official, with the concerned parties watching. That way if the vote can be called into question the ballots can be looked at.

Machine counted for initial (fast) results, Human counted with observers for certified results. In the case of US elections that would be at least 3 people counting each ballot: one independent election official, one republican and one democrat.

Mainly for latency reasons. From what I can find from a simple google search most optical cables transmit light 31% slower than in a vacuum. This means that for every 1000 km you add to the length of the cable you ad 4.8 ms of latency (if I did my math right)

4.8 ms might not seem like a lot, but when you're talk about needing speed it is one of the factors that is important. Trading, online games, etc. I'm not sure how much distance you will add if you run it up to Alaska and then over. If you're wanting to run it by land over to Alaska and then over to Japan it could be a fair amount, it might save a bunch on initial cost but will hurt latency. Plus there's Canada in the way, so you'd have to work through all that red tape too, and that might cost more (time == money) than just running it straight across the ocean.

I agree with you. For my work I would like to use classes, polymorphism, overloading (functions not operators), and pure virtual functions. Anything else on an embedded system would probably lead to bloat fast, so no templates (and STL). I would also avoid a lot of the new features like lambda functions.

We're already using classes, and pure virtual functions. It just looks ugly because we're doing it in pure C.

The arguments I usually get into are with people who think that any sort of c++ code automatically bloats the code by hundreds of percent and slows it down by 50%. The big argument I'm having right now is when we change the file extension from .c to .cpp and use the c++ compiler that the object file is suddenly larger, so it must be larger on the target and must be slower. I usually fix that by extern "c" in the header files, but I still have the same argument over and over again.

I constantly have the c vs c++ argument at work. We use c because our 'customers are afraid of c++'. But we're also doing embedded frameworks where we want to easily swap in and out drivers that follow a specific interface. And what was chosen was to use a structure of function pointers to do the interface. Others got upset when I started to label my structures with vTable for the interfaces I was creating.

I'll fully admit that c++ has it's disadvantages but when you're writing object code in c, why not use it and limit what aspects are legal?