Full Stop. The reason why tech workers are "exempt" has to do with over-time pay. Companies do not want to pay over-time. It has nothing to do with being creative.
Sorry to correct you, but since my workplace in 1986 was one of the DOL study sites that decided them to classify Software Engineering as a creative endeavor, the DOL position was arrived at without lobbying; it was not a political decision, it was an observational one.
It should perhaps be revisited, but since almost no software engineering jobs are hourly, rather than salaried these days, it hardly matters, since salaried employees are definitionally exempt in any case, so a reclassification wouldn't get you overtime anyway, unless you were a temp worker.
Internships are available. But you're late. You wanted to apply over winter for the summer internships. It's possible that you could get a later in the year internship at this point, but it could interfere with your attending school, depending on where and what hours and how many hours were expected.
Almost all CS internships pay.
Also, don't worry about how much school you have, if you are good at what you do; we had to get special dispensation for it, but we had Hexxeh (Liam McLoughlin) as an intern on the ChromeOS team at Google, and he had not graduated high school at the time. On the other hand, he was most definitely good at what he did, which included running the only external ChromeOS (ChromiumOS) buikd and distribution site since he was about 16. See: http://chromeos.hexxeh.net/
The less outstanding you are, the more education you'll have to have to get many internships, so... be outstanding, and apply next year.
Everywhere you go as a plumber, you're going to be dealing with toilets, showers, sinks, and faucets from one or two companies... Kohler, Delta, Meon. They'll all use the same size connectors, and the same size holes in the vanity, and the same size wrench for connecting the water inflow, and the same size pipe for the water outflow, etc., etc.. It's a skilled job that can be learned, because it's possible to learn *all of it*.
CS people generally do not go through an apprenticeship. Writing code is not a blue-collar job, it's a creative job. This is why the Department of Labor considers CS people "exempt" employees, not subject to overtime rules, etc.: it's more than 50% creative (look up the rules).
I know a lot of self-taught people who haven't gone to college, who have (effectively) apprenticed at their first job(s), and they're OK to do those jobs, but they require retraining for anything else, and forget it if you want them on a team, because they just don't know the jargon to communicate efficiently and effectively with their teammates who have gone to college.
I think this is one of the reasons that most companies aren't standing outside the doors of the "boot camps", waiting to catch the people who just got their certificates, and give them a job.
That's the compiler, not the language. IEEE-754 wasn't published until 1985, so the older [1977] spec doesn't say anything about it.
In any case, if you care about the difference between 80-bit extended precision and IEEE double precision, then you're either writing a compiler, dealing with an extremely stiff differential equation, or [most often] have made a poor algorithm choice and are trying to paper over algorithmic instability by throwing more bits at it.
-JS
Or I want reproducible results. It's one of the reasons that, if you are using a PRNG as an input to a montecarlo algorithm, that you want to seed it the same way each time, and you probably want to carry around your own PRNG, rather than trusting that some idiot didn't change drand48 to "make it have better entropy", rendering your computations non-reporducible.
It turns out that in Science(tm), being able to reproduce someone else's results independently ends up being "kinda important".
So, Fortran issues extra instructions and pipeline stalls for accuracy, yet manages to be faster.
That is amazing!
It's faster in areas not involving floating point, and in floating point on hardware that has a good floating point implementation.
It's easier to branch-predict fortran code, and the lack of pointer support makes the boolean algebra a lot simpler for the complier. Given the calling conventions and limits, it's actually a lot easier to optimize fortran, and given that oist matrix math involves linear loops, it's easier to autovectorize things like the Berkeley Physics package. E.g. if you are attempting to do montecarlo simulations of P-P and N-P collisions in a relativistically invariant reference frame while simulating pair production events constrained by the matrix solution to the intersection of multiple Feynman-Dyson diagrams, it will almost universally run faster if the code is in FORTRAN.
Wow, faster AND more accurate. They must use some mystical floating-point instructions that only Fortran compiler writers know about.
On PPC implementations, head-tail floating point is typically used for "long double"; this leads to inaccuracies in calculations. 80 bit Intel floating point is also inaccurate. So are SSE "vector" instructions, since denormals, NaNs, INFs, and -0 are always suspect unless you compiler emits an extra instruction in order to trigger the "next instruction after" signalling of the condition, and for NaNs, you are still somewhat suspect there.
If it isn't IEEE-754 compliant, you pretty much can't trust it. FORTRAN goes way the heck out of its way, including issuing additional instructions and introducing pipeline stalls, in order to force IEE-754 compliance.
Pretty much this accuracy only matters if you are doing Science(tm); if you are doing graphics, you are generally willing to eat the occasional FP induced artifact, because what you typically care about is the frame rate in your game, rather than being 100% accurate.
So, in closing, they're not using "some mystical floating-point instructions", they are just using accurate floating point, rather than approximate floating point.
I have never, ever, ever seen a course catalog that lists CS 201 FORTRAN PROGRAMMING.
I guess it's "bear in the woods" time...
That is because you are a kid who learned after 1986 in the U.S., after they changed the accreditation standards, and caused the next crop of CS graduates to not have learned programming languages specifically (i.e. caused then to learn their tools, as opposed to "learn the tools on your own and apply them to a problem domain"). That change is one of the reasons it's frequently more useful to hire people graduating from European Universities than U.S. Universities, and why we need so many H1-B visas for those folks: U.S. Students know theory, but can't code, because they don't know how to use their tools, unless they come out of a college or university that offers non-acreddited language courses on top of the rest of the curriculum - e.g. Rice University, Brown University, and so on, or they otherwise mastered (not just learned) them on their own.
https://archive.org/details/co... Illinois State University course catalog, 1982 - Pg 53 - Applied Computer Science Courses 164 INTRODUCTION TO FORTRAN PROGRAMMING 169 INFORMATION PROCESSING USING PL/1 265 JOB CONTROL LANGUAGE 272 COBOL AS A SECOND LANGUAGE 274 PL/1 AS A SECOND LANGUAGE 283 ASSEMBLER LANGUAGE PROGRAMMING 288 ADVANCED ASSEMBLER LANGUAGE PROGRAMMING
CS Used to be taught very differently than it is today. Today, ABET Accreditation requires that you implement "Outcome Based Courses", which means that it's really not about coding any more, it's about documenting a process, and then documenting that you followed that process. See also:
Anyone worth hiring today that graduated with a U.S. CS degree in the last two and a half decades graduated from one of a handful of universities with "Extra requirements" that include actually learning specific computer languages, or included self-directed programs, where one of the options was learning one or more specific computer languages. Or they have been involved in one or more large Open Source projects where participation required that they learn one or more specific computer languages, and that they actually participated more than tangentially in the project.
I've seen many outstanding U.S. candidates, as an interviewer, and either they graduated before 1986-1988, OR they went to one of those universities, OR they participated heavily in an Open Source project. Very few not in one (or more) of those buckets were what I would call "top tier candidates".
Example: I pick a random POSIX-2001 function (let's not worry about all the large file cruft and other APIs that came about because some OS vendors were to lazy to implement per-thread working directories or credentials; we'll make it easy). Can you describe it's parameters and return values without looking at the man page? OK, that might not be entirely fair; random might get me something like "poll", with structure inputs, etc. -- how about if I picked 8 of them; could you describe the parameters and outputs of at least 8 of them?
I think the answer for most people on that question will be "no" - because they don't know the libraries in the UNIX Programming Environment, which are one of their most important tools. These are the people most likely to implement their own version of strncmp(3) because they don't realize that there's an existing function that solves the problem. They are the people who aren't going to realize that asprintf(3) allocated memory which they are responsible for freeing later, intil the memory leak in their code bites them in the butt.
If you want to say "But I don't program a UNIX system, I program Windows!", I invite you to explain CoCreateFreeThreadedMarshaler(
Google's bus system works better because it runs on a monster budget compared to public transit. Not because it's more clever or efficient. They're just willing to dump healthy sums of money into giving their employees a ride to work, because they have so much money they don't really know what to do with it (which is why they came up with Google X labs way back when - to find new things to do with the money).
Nice theory. Except SF Muni is funded to the tune of almost $1B, less than 25% of which comes from fares; the rest of what they consider "revenue" comes from (in order):
- 32.7% Parking & Traffic fees and fines - 26.0% General Fund - 13.6% Operating grants (this includes the one from Google) - 2.6% Advertising, interest, and service fees - 1.2% Charges for taxi services (medalians, maintaining the Taxi monopoly, etc.)
So let me call BS right there. There's no way in hell Google is dropping $1B worldwide for all their transit to and from Google, even if you include worldwide, all of them.
Technically, if they could be ~23% more efficient, then Muni would not have to charge fares at all, and they'd still have adequate "revenue" to cover their operating costs.
Most people who learned FORTRAN did so in a class intended to teach FORTRAN.
Most people these days aren't learning FORTRAN, they're learning other languages, and they're doing them in a context that teaches them about apply the tool, rather than making them really, really good with the tool itself.
To use an analogy, it's the difference between learning how to use all the tools in the wood shop before being sent in to make a chair (learn the tools) vs. being taught all about "chairness", and then being sent in to make a chair, without a great knowledge of the tools themselves. Someone is going to lose a finger, in the second case.
So it might be "legacy", but the legacy they want is the teaching methods which were in use when most of the FORTRAN programmers came into existence in the first place.
and what will the other 99.99% of the population be able to afford???
A subsidized bus pass that some city with a non-functional, useless public transit system has blackmailed out of a high tech company, out of anger for them running a private workable public transit system and demonstrating that it's the idiots in charge of administering the public transit system who are fault for it being crappy, rather than funding or some other reason?
Isolate the protiens the young mice have that the old mice don't have. Blood transfusions aren't necessary... Just saline and protien.
The previous studies that had the same result eventually concluded that it was the pluripotent stem cells in the blood which had come out of the marrow as part of normal blood production.
On this basis, a treatment was developed (and insurance approved) using autologous stem cell transplantation; it's a common treatment for some types of cardiac events. There are also transplants involving harvesting of marrow stem cells, and then separating leukotic stem cells from those which are non-leukotic, and then growing and storing them while the patient undergoes radiation or chemotherapy to kill of their remaining marrow (this requires frequent transfusions to keep the blood volume of functional cells up, as the body is no longer replacing them itself at a high enough rate). Subsequent to this, the saved and separated cells are then transplanted back into the long bones (the rest of the interior areas of the smaller bones are allowed to be recolonoized by stem cells that escape the long bones). Since the treaments are autologous, you about conditions like interstitial pneomonitis, or the need for anti-rejection therapy, which is sometimes problematic when using a heterologous cell source.
So would warning about dead code, since the code past the point of the second goto is, by definition, dead code. Most people prefer automatic dead code elimination, mostly because they don't want to have to fix their code, if they could be working on new code instead.
When I turned on the "Brucification" warnings in the Mac OS X compiles, everyone bitched they couldn't see the new warnings their changes introduced with the previous (small) set of warnings that they personally cared about were all the compiler would complain about. We found tons of code in the VM system and elsewhere which was dead (most of them intended as code path optimizations, which is funny because performance testing would have found they didn't have any impact) because of "comparison is always true..." or "comparison is always false..." rendering them silently dead.
Unfortunately, -Wunreachable-code was removed from gcc in 2010 (brilliant move, that, in retrospect, wasn't it?).
Me too. I should have stopped at the "which it is".
It's a total jingoistic piece that's more or less written as a rant about how much nicer things used to be, before the (presumed) current tech bubble.
Why do we care if large "funny money" transactions are happening? It's not like an all stock purchase of supposedly valueless companies by a supposedly valueless company matters to anyone, in an economic sense.
I have no idea why he brings up BofA, which has little to do with tech funding, why he brings up "Google Busses" then references a much better article that disproves his own thesis, ageism (except at HP, IBM, and Oracle), why anyone in SV should care about Oakland falling into a huge crack in the Earth, or why the Market street "gentrification" (which was disproven by the article he brought up during his discussion of "Google Busses").
But I guess some Wookies *do* want to live on Endor... or it would make no sense, right?
"Yum! was created on May 30, 1997, as Tricon Global Restaurants, Inc. an independent company, as a result of a spin-out of the former fast food division of PepsiCo, which owned and franchised the KFC, Pizza Hut, and Taco Bell brands worldwide. Because of the company's previous relationship with Pepsi, Yum! Brands has a lifetime contract with PepsiCo"
It makes sense that Pepsi would decline the offer, since in blind taste tests most people prefer Pepsi.
This is pretty hilarious, seeing that Pepsi had to, at one point, buy Taco Bell, Pizza Hut, and Kentucky Fried Chicken before they could force them into contracts that obligated them to buying Pepsi products, since no one wanted to sell Pepsi.
In addition, any civilization THAT advanced would undoubtedly be able to get better efficiency out of their reactors before zipping away.
My guess is they'd also be running reactors that could use the fuel up more or less completely, resulting in far less spent fuel being produced, if any.
You know, kind of like France does, with their spent fuel reprocessing and use of breeder reactors...
Linux doesn't retry the EDID with the video drivers, so for multichannel monitors with the Linux box hooked up to a secondary channel, it won't negotiate the screen settings correctly.
Why not?
For Samsung and Toshiba televisions, you can either blame the television, or you can blame Linux.
If you want to blame the television, then it's the lack of EDID negotiation on input channels that are not the current display input. You can blame this on the lack of multithreading in the embedded controller in the television, since electrically, there's no reason that an active input channel shouldn't be negotiating EDID information,
If you want to blame Linux, you can blame the video drivers themselves for not retrying, and you can blame X/Wayland/etc. for not forcing them to retry and delaying picking a display resolution until there's a successful EDID negotiation.
Philips had a similar issue with their DVD players when started on a secondary channel; they made a change to the DVD players and to the televisions themselves. The change to the television was that, when an input came active, the television automatically switch to the input so that it would "be there" for the negotiation phase. The change to the DVD player was to retry the EDID negotiation when it didn't get an answer from the television. In addition, when it's in "sleep mode", the DVD player will wake up when the input channel is selected.
The end result is that the DVD player comes up in a lower default resolution that's generally supported by all TV's, and then pops to the highest supported resolution in common between the player and the TV. The upshot of this is you get to see the screen change modes when you start up the DVD player.
FWIW, this first came to the attention of the ChromeOS team when we threw an I2C analyzer on the bus to watch the EDID negotiation, and it became pretty obvious what was happening. If you don't have the actual source code for the video card driver, this is a hard problem to correct without doing some reverse engineering, since it's pretty common for binary Linux drivers from the video card vendor to not do the retry and/or delay the X startup until the EDID resolution negotiation has taken place, so that you know what resolution you're going to be running at when you bring up the display server.
Personally, I think the right thing to do is fix both ends of the problem, so if you end up with an old monitor/new computer, or vice versa, Things Just Work(tm).
Linux doesn't retry the EDID with the video drivers, so for multichannel monitors with the Linux box hooked up to a secondary channel, it won't negotiate the screen settings correctly.
You see this a lot when using the larger Dell monitors, and also when using Samsung televisions as monitors. The workaround is to put the device on the first input channel, which is the default selection for the monitor when there's no video input negotiation. Basically, if you aren't the active video channel, Linux tries to negotiate with what's effectively a dead port until you switch it, and the Samsung TVs like to go back to active input sources when a video channel goes out - so you end up not having it selected when it's trying to chat about the EDID, and once it's failed at that, then you switch over, you don't have the right output.
Unfortunately, some of the monitors have a primary HDMI vs. DVI input as the default input, and for those monitors, unless you use the right connector, it'll never negotiate correctly.
Someone really needs to separate the EDID negotiation out so that it can be put in common upper level code.
Google employees benefit from the roads, drinking water and municipal/government services that allowed them to set up shop in France as opposed to, say, the Antarctic. Go there if you think you need the freeeeeduuuumb.
Actually, a lot of us would, only there are international agreements to prevent people colonizing there, and pretty much creating new nations anywhere. When it looks like it's about to happen somewhere, it gets stopped. E.g. the Minerva Reefs were underwater atolls that was landfilled by a libertarian group seeking to become a new nation state in 1972, at which point the U.S. Government paid Tonga to send the Tongan navy to go plant a Tongan flag on them. They were basically their own country for a grand total of 26 days. It was claimed on the basis of territorial fishing outside the internationally recognized 2 mile coastal limit. Right now they are completely unoccupied, but the Tongan Navy shows up any time someone tries to occupy the area (good enough to keep other people from living there, not good enough to live there themselves), as it did again in 1982. Ironically, Fiji, one of the countries that rubber-stamped the Tongan claim initially at the behest of the U.S. is now trying to dispute the territorial waters claims, since they now want fishing rights to the area as well.
As far as paying for things: the Google employees enjoying French services are socked with a 66% payroll tax (do you really think the employer pays this tax? This is income that you would get that the employer gives the government instead), and on the remaining 34% which is their take home pay, they pay up to a 45% personal income tax (the top rate is at 70,830 Euros, which is just under US$100,000, which is an easy amount to get as a Google employee after just a couple of years out of college, assuming you don't suck).
So they are getting about US$111,000 per Google employee... and they want more.
Google seems to be consistently dodging taxes. Shouldn't people go to jail for this?
If you set up rules by which something is legal, and someone jumps through the necessary hoops to follow those rules in order to pay the minimum possible taxes, the only thing you really have a right to complain about is the rules you've set up, not that people follow them in an optimal fashion.
France is (effectively) paying Google $266.5M to execute their contracts in Ireland rather than France, due to the 33.3% corporate tax in France, vs. the 12.5% corporate tax in Ireland.
If France wants to tariff EU transactions, they need to drop out of the EU; if they want the $162.5M from Google that's going to Ireland instead of France, then they need to drop their corporate tax rate by 20.8% to match Irelands...or drop out of the EU.
If it weren't for the loading (multiple incorporations, intellectual property assets capable of being licensed for large feed, lawyer costs, professional board member costs in the NL, etc.), pretty much no one would actually do business in France directly, as a legal venue.
Slashdot Mirror
Full Stop. The reason why tech workers are "exempt" has to do with over-time pay. Companies do not want to pay over-time. It has nothing to do with being creative.
Sorry to correct you, but since my workplace in 1986 was one of the DOL study sites that decided them to classify Software Engineering as a creative endeavor, the DOL position was arrived at without lobbying; it was not a political decision, it was an observational one.
It should perhaps be revisited, but since almost no software engineering jobs are hourly, rather than salaried these days, it hardly matters, since salaried employees are definitionally exempt in any case, so a reclassification wouldn't get you overtime anyway, unless you were a temp worker.
Internships are available. But you're late. You wanted to apply over winter for the summer internships. It's possible that you could get a later in the year internship at this point, but it could interfere with your attending school, depending on where and what hours and how many hours were expected.
Almost all CS internships pay.
Also, don't worry about how much school you have, if you are good at what you do; we had to get special dispensation for it, but we had Hexxeh (Liam McLoughlin) as an intern on the ChromeOS team at Google, and he had not graduated high school at the time. On the other hand, he was most definitely good at what he did, which included running the only external ChromeOS (ChromiumOS) buikd and distribution site since he was about 16. See: http://chromeos.hexxeh.net/
The less outstanding you are, the more education you'll have to have to get many internships, so ... be outstanding, and apply next year.
Trade apprenticeships are not comparable.
Everywhere you go as a plumber, you're going to be dealing with toilets, showers, sinks, and faucets from one or two companies... Kohler, Delta, Meon. They'll all use the same size connectors, and the same size holes in the vanity, and the same size wrench for connecting the water inflow, and the same size pipe for the water outflow, etc., etc.. It's a skilled job that can be learned, because it's possible to learn *all of it*.
CS people generally do not go through an apprenticeship. Writing code is not a blue-collar job, it's a creative job. This is why the Department of Labor considers CS people "exempt" employees, not subject to overtime rules, etc.: it's more than 50% creative (look up the rules).
I know a lot of self-taught people who haven't gone to college, who have (effectively) apprenticed at their first job(s), and they're OK to do those jobs, but they require retraining for anything else, and forget it if you want them on a team, because they just don't know the jargon to communicate efficiently and effectively with their teammates who have gone to college.
I think this is one of the reasons that most companies aren't standing outside the doors of the "boot camps", waiting to catch the people who just got their certificates, and give them a job.
No, this means that you don't understand physics.
For someone who understands physics so well, you'd think you'd put a flywheel on your bike so that stopping wasn't an issue.
I should of stated "most people don't ride when it's 20 degrees F."
I think the phrase you were actually looking for was "sane people don't ride when it's 20 degrees F.".
That's the compiler, not the language. IEEE-754 wasn't published until 1985, so the older [1977] spec doesn't say anything about it.
In any case, if you care about the difference between 80-bit extended precision and IEEE double precision, then you're either writing a compiler, dealing with an extremely stiff differential equation, or [most often] have made a poor algorithm choice and are trying to paper over algorithmic instability by throwing more bits at it.
-JS
Or I want reproducible results. It's one of the reasons that, if you are using a PRNG as an input to a montecarlo algorithm, that you want to seed it the same way each time, and you probably want to carry around your own PRNG, rather than trusting that some idiot didn't change drand48 to "make it have better entropy", rendering your computations non-reporducible.
It turns out that in Science(tm), being able to reproduce someone else's results independently ends up being "kinda important".
So, Fortran issues extra instructions and pipeline stalls for accuracy, yet manages to be faster.
That is amazing!
It's faster in areas not involving floating point, and in floating point on hardware that has a good floating point implementation.
It's easier to branch-predict fortran code, and the lack of pointer support makes the boolean algebra a lot simpler for the complier. Given the calling conventions and limits, it's actually a lot easier to optimize fortran, and given that oist matrix math involves linear loops, it's easier to autovectorize things like the Berkeley Physics package. E.g. if you are attempting to do montecarlo simulations of P-P and N-P collisions in a relativistically invariant reference frame while simulating pair production events constrained by the matrix solution to the intersection of multiple Feynman-Dyson diagrams, it will almost universally run faster if the code is in FORTRAN.
Wow, faster AND more accurate. They must use some mystical floating-point instructions that only Fortran compiler writers know about.
On PPC implementations, head-tail floating point is typically used for "long double"; this leads to inaccuracies in calculations. 80 bit Intel floating point is also inaccurate. So are SSE "vector" instructions, since denormals, NaNs, INFs, and -0 are always suspect unless you compiler emits an extra instruction in order to trigger the "next instruction after" signalling of the condition, and for NaNs, you are still somewhat suspect there.
If it isn't IEEE-754 compliant, you pretty much can't trust it. FORTRAN goes way the heck out of its way, including issuing additional instructions and introducing pipeline stalls, in order to force IEE-754 compliance.
Pretty much this accuracy only matters if you are doing Science(tm); if you are doing graphics, you are generally willing to eat the occasional FP induced artifact, because what you typically care about is the frame rate in your game, rather than being 100% accurate.
So, in closing, they're not using "some mystical floating-point instructions", they are just using accurate floating point, rather than approximate floating point.
I have never, ever, ever seen a course catalog that lists CS 201 FORTRAN PROGRAMMING.
I guess it's "bear in the woods" time...
That is because you are a kid who learned after 1986 in the U.S., after they changed the accreditation standards, and caused the next crop of CS graduates to not have learned programming languages specifically (i.e. caused then to learn their tools, as opposed to "learn the tools on your own and apply them to a problem domain"). That change is one of the reasons it's frequently more useful to hire people graduating from European Universities than U.S. Universities, and why we need so many H1-B visas for those folks: U.S. Students know theory, but can't code, because they don't know how to use their tools, unless they come out of a college or university that offers non-acreddited language courses on top of the rest of the curriculum - e.g. Rice University, Brown University, and so on, or they otherwise mastered (not just learned) them on their own.
https://archive.org/details/co...
Illinois State University course catalog, 1982 - Pg 53 - Applied Computer Science Courses
164 INTRODUCTION TO FORTRAN PROGRAMMING
169 INFORMATION PROCESSING USING PL/1
265 JOB CONTROL LANGUAGE
272 COBOL AS A SECOND LANGUAGE
274 PL/1 AS A SECOND LANGUAGE
283 ASSEMBLER LANGUAGE PROGRAMMING
288 ADVANCED ASSEMBLER LANGUAGE PROGRAMMING
CS Used to be taught very differently than it is today. Today, ABET Accreditation requires that you implement "Outcome Based Courses", which means that it's really not about coding any more, it's about documenting a process, and then documenting that you followed that process. See also:
ABET - Criteria for Accrediting Computing Programs, 2012 - 2013
http://www.abet.org/DisplayTem...
Anyone worth hiring today that graduated with a U.S. CS degree in the last two and a half decades graduated from one of a handful of universities with "Extra requirements" that include actually learning specific computer languages, or included self-directed programs, where one of the options was learning one or more specific computer languages. Or they have been involved in one or more large Open Source projects where participation required that they learn one or more specific computer languages, and that they actually participated more than tangentially in the project.
I've seen many outstanding U.S. candidates, as an interviewer, and either they graduated before 1986-1988, OR they went to one of those universities, OR they participated heavily in an Open Source project. Very few not in one (or more) of those buckets were what I would call "top tier candidates".
Example: I pick a random POSIX-2001 function (let's not worry about all the large file cruft and other APIs that came about because some OS vendors were to lazy to implement per-thread working directories or credentials; we'll make it easy). Can you describe it's parameters and return values without looking at the man page? OK, that might not be entirely fair; random might get me something like "poll", with structure inputs, etc. -- how about if I picked 8 of them; could you describe the parameters and outputs of at least 8 of them?
I think the answer for most people on that question will be "no" - because they don't know the libraries in the UNIX Programming Environment, which are one of their most important tools. These are the people most likely to implement their own version of strncmp(3) because they don't realize that there's an existing function that solves the problem. They are the people who aren't going to realize that asprintf(3) allocated memory which they are responsible for freeing later, intil the memory leak in their code bites them in the butt.
If you want to say "But I don't program a UNIX system, I program Windows!", I invite you to explain CoCreateFreeThreadedMarshaler(
Google's bus system works better because it runs on a monster budget compared to public transit. Not because it's more clever or efficient. They're just willing to dump healthy sums of money into giving their employees a ride to work, because they have so much money they don't really know what to do with it (which is why they came up with Google X labs way back when - to find new things to do with the money).
Nice theory. Except SF Muni is funded to the tune of almost $1B, less than 25% of which comes from fares; the rest of what they consider "revenue" comes from (in order):
- 32.7% Parking & Traffic fees and fines
- 26.0% General Fund
- 13.6% Operating grants (this includes the one from Google)
- 2.6% Advertising, interest, and service fees
- 1.2% Charges for taxi services (medalians, maintaining the Taxi monopoly, etc.)
Source: http://www.sfmta.com/sites/def...
So let me call BS right there. There's no way in hell Google is dropping $1B worldwide for all their transit to and from Google, even if you include worldwide, all of them.
Technically, if they could be ~23% more efficient, then Muni would not have to charge fares at all, and they'd still have adequate "revenue" to cover their operating costs.
A: Legacy code.
Most people who learned FORTRAN did so in a class intended to teach FORTRAN.
Most people these days aren't learning FORTRAN, they're learning other languages, and they're doing them in a context that teaches them about apply the tool, rather than making them really, really good with the tool itself.
To use an analogy, it's the difference between learning how to use all the tools in the wood shop before being sent in to make a chair (learn the tools) vs. being taught all about "chairness", and then being sent in to make a chair, without a great knowledge of the tools themselves. Someone is going to lose a finger, in the second case.
So it might be "legacy", but the legacy they want is the teaching methods which were in use when most of the FORTRAN programmers came into existence in the first place.
and what will the other 99.99% of the population be able to afford???
A subsidized bus pass that some city with a non-functional, useless public transit system has blackmailed out of a high tech company, out of anger for them running a private workable public transit system and demonstrating that it's the idiots in charge of administering the public transit system who are fault for it being crappy, rather than funding or some other reason?
Isolate the protiens the young mice have that the old mice don't have. Blood transfusions aren't necessary... Just saline and protien.
The previous studies that had the same result eventually concluded that it was the pluripotent stem cells in the blood which had come out of the marrow as part of normal blood production.
On this basis, a treatment was developed (and insurance approved) using autologous stem cell transplantation; it's a common treatment for some types of cardiac events. There are also transplants involving harvesting of marrow stem cells, and then separating leukotic stem cells from those which are non-leukotic, and then growing and storing them while the patient undergoes radiation or chemotherapy to kill of their remaining marrow (this requires frequent transfusions to keep the blood volume of functional cells up, as the body is no longer replacing them itself at a high enough rate). Subsequent to this, the saved and separated cells are then transplanted back into the long bones (the rest of the interior areas of the smaller bones are allowed to be recolonoized by stem cells that escape the long bones). Since the treaments are autologous, you about conditions like interstitial pneomonitis, or the need for anti-rejection therapy, which is sometimes problematic when using a heterologous cell source.
See also: http://en.wikipedia.org/wiki/A...
We should increase password strength rules!
Right now, at most sites, the strength rules are such that they disallow a significant portion of the unconstrained search space.
If we keep increasing the number of constraints, we will further reduce the search space.
Eventually, we will get to the point where I only have to remember one password, because it's the only password I, or anyone else, is allowed to have.
The LLVM static analyzer finds this bug.
So would warning about dead code, since the code past the point of the second goto is, by definition, dead code. Most people prefer automatic dead code elimination, mostly because they don't want to have to fix their code, if they could be working on new code instead.
When I turned on the "Brucification" warnings in the Mac OS X compiles, everyone bitched they couldn't see the new warnings their changes introduced with the previous (small) set of warnings that they personally cared about were all the compiler would complain about. We found tons of code in the VM system and elsewhere which was dead (most of them intended as code path optimizations, which is funny because performance testing would have found they didn't have any impact) because of "comparison is always true..." or "comparison is always false..." rendering them silently dead.
Unfortunately, -Wunreachable-code was removed from gcc in 2010 (brilliant move, that, in retrospect, wasn't it?).
I have no idea why you're maintaining that "Republicans" create these bugs, and I'm, like, a socialist.
I think he's claiming non-Republicans can't code...
Me too. I should have stopped at the "which it is".
It's a total jingoistic piece that's more or less written as a rant about how much nicer things used to be, before the (presumed) current tech bubble.
Why do we care if large "funny money" transactions are happening? It's not like an all stock purchase of supposedly valueless companies by a supposedly valueless company matters to anyone, in an economic sense.
I have no idea why he brings up BofA, which has little to do with tech funding, why he brings up "Google Busses" then references a much better article that disproves his own thesis, ageism (except at HP, IBM, and Oracle), why anyone in SV should care about Oakland falling into a huge crack in the Earth, or why the Market street "gentrification" (which was disproven by the article he brought up during his discussion of "Google Busses").
But I guess some Wookies *do* want to live on Endor... or it would make no sense, right?
"Yum! was created on May 30, 1997, as Tricon Global Restaurants, Inc. an independent company, as a result of a spin-out of the former fast food division of PepsiCo, which owned and franchised the KFC, Pizza Hut, and Taco Bell brands worldwide. Because of the company's previous relationship with Pepsi, Yum! Brands has a lifetime contract with PepsiCo"
Also, here's the citation Wikipedia is missing: https://www.princeton.edu/~ach...
It makes sense that Pepsi would decline the offer, since in blind taste tests most people prefer Pepsi.
This is pretty hilarious, seeing that Pepsi had to, at one point, buy Taco Bell, Pizza Hut, and Kentucky Fried Chicken before they could force them into contracts that obligated them to buying Pepsi products, since no one wanted to sell Pepsi.
In addition, any civilization THAT advanced would undoubtedly be able to get better efficiency out of their reactors before zipping away.
My guess is they'd also be running reactors that could use the fuel up more or less completely, resulting in far less spent fuel being produced, if any.
You know, kind of like France does, with their spent fuel reprocessing and use of breeder reactors...
Linux doesn't retry the EDID with the video drivers, so for multichannel monitors with the Linux box hooked up to a secondary channel, it won't negotiate the screen settings correctly.
Why not?
For Samsung and Toshiba televisions, you can either blame the television, or you can blame Linux.
If you want to blame the television, then it's the lack of EDID negotiation on input channels that are not the current display input. You can blame this on the lack of multithreading in the embedded controller in the television, since electrically, there's no reason that an active input channel shouldn't be negotiating EDID information,
If you want to blame Linux, you can blame the video drivers themselves for not retrying, and you can blame X/Wayland/etc. for not forcing them to retry and delaying picking a display resolution until there's a successful EDID negotiation.
Philips had a similar issue with their DVD players when started on a secondary channel; they made a change to the DVD players and to the televisions themselves. The change to the television was that, when an input came active, the television automatically switch to the input so that it would "be there" for the negotiation phase. The change to the DVD player was to retry the EDID negotiation when it didn't get an answer from the television. In addition, when it's in "sleep mode", the DVD player will wake up when the input channel is selected.
The end result is that the DVD player comes up in a lower default resolution that's generally supported by all TV's, and then pops to the highest supported resolution in common between the player and the TV. The upshot of this is you get to see the screen change modes when you start up the DVD player.
FWIW, this first came to the attention of the ChromeOS team when we threw an I2C analyzer on the bus to watch the EDID negotiation, and it became pretty obvious what was happening. If you don't have the actual source code for the video card driver, this is a hard problem to correct without doing some reverse engineering, since it's pretty common for binary Linux drivers from the video card vendor to not do the retry and/or delay the X startup until the EDID resolution negotiation has taken place, so that you know what resolution you're going to be running at when you bring up the display server.
Personally, I think the right thing to do is fix both ends of the problem, so if you end up with an old monitor/new computer, or vice versa, Things Just Work(tm).
Linux doesn't retry the EDID with the video drivers, so for multichannel monitors with the Linux box hooked up to a secondary channel, it won't negotiate the screen settings correctly.
You see this a lot when using the larger Dell monitors, and also when using Samsung televisions as monitors. The workaround is to put the device on the first input channel, which is the default selection for the monitor when there's no video input negotiation. Basically, if you aren't the active video channel, Linux tries to negotiate with what's effectively a dead port until you switch it, and the Samsung TVs like to go back to active input sources when a video channel goes out - so you end up not having it selected when it's trying to chat about the EDID, and once it's failed at that, then you switch over, you don't have the right output.
Unfortunately, some of the monitors have a primary HDMI vs. DVI input as the default input, and for those monitors, unless you use the right connector, it'll never negotiate correctly.
Someone really needs to separate the EDID negotiation out so that it can be put in common upper level code.
Google employees benefit from the roads, drinking water and municipal/government services that allowed them to set up shop in France as opposed to, say, the Antarctic. Go there if you think you need the freeeeeduuuumb.
Actually, a lot of us would, only there are international agreements to prevent people colonizing there, and pretty much creating new nations anywhere. When it looks like it's about to happen somewhere, it gets stopped. E.g. the Minerva Reefs were underwater atolls that was landfilled by a libertarian group seeking to become a new nation state in 1972, at which point the U.S. Government paid Tonga to send the Tongan navy to go plant a Tongan flag on them. They were basically their own country for a grand total of 26 days. It was claimed on the basis of territorial fishing outside the internationally recognized 2 mile coastal limit. Right now they are completely unoccupied, but the Tongan Navy shows up any time someone tries to occupy the area (good enough to keep other people from living there, not good enough to live there themselves), as it did again in 1982. Ironically, Fiji, one of the countries that rubber-stamped the Tongan claim initially at the behest of the U.S. is now trying to dispute the territorial waters claims, since they now want fishing rights to the area as well.
As far as paying for things: the Google employees enjoying French services are socked with a 66% payroll tax (do you really think the employer pays this tax? This is income that you would get that the employer gives the government instead), and on the remaining 34% which is their take home pay, they pay up to a 45% personal income tax (the top rate is at 70,830 Euros, which is just under US$100,000, which is an easy amount to get as a Google employee after just a couple of years out of college, assuming you don't suck).
So they are getting about US$111,000 per Google employee ... and they want more.
Google seems to be consistently dodging taxes. Shouldn't people go to jail for this?
If you set up rules by which something is legal, and someone jumps through the necessary hoops to follow those rules in order to pay the minimum possible taxes, the only thing you really have a right to complain about is the rules you've set up, not that people follow them in an optimal fashion.
France is (effectively) paying Google $266.5M to execute their contracts in Ireland rather than France, due to the 33.3% corporate tax in France, vs. the 12.5% corporate tax in Ireland.
If France wants to tariff EU transactions, they need to drop out of the EU; if they want the $162.5M from Google that's going to Ireland instead of France, then they need to drop their corporate tax rate by 20.8% to match Irelands ...or drop out of the EU.
If it weren't for the loading (multiple incorporations, intellectual property assets capable of being licensed for large feed, lawyer costs, professional board member costs in the NL, etc.), pretty much no one would actually do business in France directly, as a legal venue.
The Delta MK 4 Megafighter was exactly my first thought as well... Only this video, instead... http://www.youtube.com/watch?v...
For extra geek-cred, MegaForce also starred Persis Khambatta, the actress who played V-GER in the first Star Trek movie...