orclev

Previous studies like these have generally shown that young attractive females make considerably more than male employees with a similar level of education and experience, but as you go up in age the trend reverses with older or less attractive female employees making less. Basically there is a bias, but it isn't so much gender in general as it is being attractive sexually (or not as the case may be). I'm not aware of any study that has tested if that applies to both genders (from the data it very clearly applies to females, but there may be a lesser effect applied to males as well), but that would be something interesting to look at. I suspect it would show there is a similar bias applied to males, but with a significantly smaller effect that's mostly lost in the noise.

> Doing so in a way that produces sufficient energy to sustain the fusion reaction without creating an uncontrolled reaction ("boom") is the trick that always seems to be 30 years away.

Uh, no, not really, a run away fusion reaction has never really been a concern. In fact, that's one of the biggest advantages of a fusion reactor vs. a fission reactor. Fission is a self-sustaining reaction, once it starts you have to work to stop it (via injecting a mediator to interfere in the fission reaction), where as fusion requires constant energy input in order to maintain the reaction. The part that "always seems to be 30 years away", is achieving a fusion reaction that produces more energy than it takes to maintain (allowing some of the output energy to be siphoned off to maintain the reaction). There have been a number of techniques attempted to achieve this with the holy grail being so called "cold" fusion, where cold is defined in this context as something less than the surface temperature of the sun. It sounds like the ultimate solution to the problem though is simply better magnets, not cold fusion at all.

Assuming this pans out, the real thing needed to make this viable as something other than a novelty is how much more efficient the reaction can be made. After all, if the output energy is just barely over the input energy you'd need to scale out to ridiculous extremes to produce enough usable energy, but if it's a significant amount higher then that makes more modest size plants viable.

Or this awesome issue on any of the newer MacBook Pro laptops, if you plug or unplug any USB devices while the system is either going into or recovering from sleep mode (I.E. after you've closed the lid, but before you see the login screen again after opening it), it will randomly kernel panic. I spent almost a month trying to figure out why I would randomly get a kernel panic in the morning since my evening routine was to close the lid, disconnect my keyboard/mouse/monitor, and then in the morning do the exact opposite (plugin keyboard/mouse/monitor, open lid). Once I read about the issues with USB devices and sleep mode I changed my routine to first open the lid, wait for the login screen to show up then plugin all the USB devices. Since I made that change I haven't seen a single kernel panic.

Yeah, I can see that. Basically you've got two options, go the Haskell way and have zero runtime reflection support and full type erasure, or go the C# way and have full reflection support and no type erasure. Java it's just painful because you get runtime reflection except it's incomplete because half the type info was erased at compile time.

That's not what organic means. Technically organic can mean derived from something that is/was living, but it can also mean anything that contains hydrocarbons. Similarly inorganic can mean either something not contained within anything that is/was living (which honestly with how varied life is doesn't cover much), or else something not containing carbon.

That however is the actual definition of organic as opposed to how it's used in marketing material. When talking about marketing, organic just means that a particular subset of approved pesticides and possibly fertilizers, was used in growing the produce. It has no particular meaning beyond that when used as a marketing term. In particular what pesticides are or are not approved is at the discretion of the organization providing the organic certification, so depending on where you are and what group is certifying a product as organic will determine what was used in growing it.

In most places in order to qualify as "organic" they're only allowed to use a certain subset of pesticides (generally ones derived from natural sources such as bugs or other plants). They aren't pesticide free, and there's no requirement on the quantities of pesticides used, only the kinds of pesticide. There's also no requirements around fertilizer used as far as I'm aware. Like most of the health buzzword fads, organic doesn't really mean what most people think it means, and in truth what it means is highly variable depending on who's using the term.

* No

* Don't Care

* Uh... maybe? There is some merit in having a localized indicator of approximately where in a given day cycle a particular location is, E.G. if I call someone on the other side of the planet knowing they're local time gives me some idea of how much I will or won't be annoying them. On the other hand, UTC is massively useful and the fact that we have almost no awareness of it in our daily lives is kind of problematic as well.

Both you and madez are correct, although I still agree with the principle behind the original statement. IME (and the AMD and ARM equivalents) are a gaping security hole in all modern processors and that should terrify everyone who cares about security at all. Think about things like Meltdown and Spectre and that's in parts of the processor we can actually audit, now consider all the exploitable flaws that are lurking in things like IME that we (although presumably nation states can) can't audit.

Which is half true. All of them are vulnerable to Spectre. So far as I've heard only Intel (and maybe ARM) are vulnerable to Meltdown, because Meltdown exploits the lack of security checks on speculative execution that only Intel implemented. It's ambiguous if ARM is vulnerable, I've only heard people saying either "maybe" or that they haven't validated that.

Edit: Elsewhere I found a link to ARMs page where they breakdown exactly which of their processors are vulnerable to both Metldown and Spectre and it looks like quite a few of them are vulnerable to one or both of them.

I just lift my legs a little which completely blocks them from reclining because at that point my knees are pressed into the seat when it's fully upright. They literally can't recline because there's no room to do so. Airlines have reached the point where in a lot of cases there is no room between the seats when they're fully upright, unless the seat behind the passenger is empty it physically can't recline.

Obviously there's the question of how foolproof you want the system to be, but at a minimum there should be some system that monitors and confirms it's receiving at least a heartbeat signal from the camera and that the camera is reporting normal functioning. If the camera drops out police dispatch should be notified who in turn should notify the officer that he needs to return to the station to have his camera replaced. One possibly more passive solution that others have mentioned is to simply discount any testimony an officer provides that doesn't have an operating camera to corroborate his statements and instead defer to non-law enforcement testimony in those cases instead of the current situation where an officer is always considered more trustworthy than anyone else. That provides very strong incentive for police to insure their cameras are working because in the event they aren't any testimony they provide would be more or less nullified and likely lose them cases.

Malicious intent must be assumed. The body cameras exist in order to be a deterrent to malicious police behaviors and as such any system which puts the officers in charge of the functioning of the cameras, and which does not heavily discourage or prevent police from operating with a broken or malfunctioning camera is failing in its primary mission. It should be illegal for an officer to operate or be on duty with a broken or otherwise non-functioning body camera, and the footage from body cameras should be held by an independent third party that is not subject to oversight or control by the police (FBI might not be a bad idea).

Cyclists shouldn't be on the road in the first place. They're a non-powered vehicle and as such are pedestrians same as someone on a skateboard. They either need to be on sidewalks, or have their own separate paths (that are physically separate from roads which are for powered vehicles only). As for non-driverless cars (driven cars?) that's a more complicated problem, but as they become increasingly less common they should eventually get their own dedicated lanes to keep them out of the way of the driverless cars. Eventually we'll likely see a bifurcated system where driverless cars operate at much higher speeds that they can safely do (say 100+ mph in some areas), while manually driven cars are restricted to speeds more appropriate for human reflexes and awareness, say something averaging about 50 mph with some sections getting up to 80 mph or so.

This is such a clear and obvious solution I'm surprised this is even a story.

Not really, I mean, your opponent is the one controlling the size of the thing you're trying to intercept and they're not going to be trying to make things easier on you. The only viable option given that is to go for area saturation and basically play the odds, but that's really expensive because not only do you need lots of interceptors in that case, but each one needs to be capable of getting a kinetic kill since there's no guarantee which one (if any) will actually hit. At some point I imagine the interceptors become a bigger danger to each other than they are to the thing you're trying to intercept.

It also has that snarky little footnote saying that a "TTL" isn't the same thing as an expiration time next to the entry claiming vault doesn't support secret expiration.

Not just that, source code should really be viewed as a toxic byproduct, the more of it you generate, the more you're going to be paying in maintaining and managing it. The best code you can write, is the code that meets your current needs in as succinct a way as possible. Further anything that's internet facing is even more critical to minimize, failure to properly deal with it (keep it up to date and stay on top of known vulnerabilities) can and will sink a business when that bit rot eventually leads to an Experian type situation.

I think what you're missing is that GraphQL isn't SQL, but rather a SQL-ish query language that supports a limited subset of what SQL does. Additionally, GraphQL lets the server define the schema that's being exposed to the client independent of the actual storage underneath that, including defining and limiting the types of mutations that can be applied. If you were to simply expose the ability for clients to feed SQL queries into your backend then you have to worry about policing those queries, scrubbing problematic values out of the queries, and in general preventing users from doing bad things with your database. By exposing a GraphQL interface you're providing a limited and tightly controlled view into your data, but still allowing the client the freedom to specify the shape and partitioning of the data being returned.

I think Gepsens argument was that your not achieving the same pattern, rather your achieving a subset of the pattern where several important considerations in dealing with a distributed system have been ignored and/or are unsupported. Once you do add those features back in then you basically arrive at Kafka and all the complexity involved with standing it up, so Redis isn't really an Apples to Apples comparison. While it certainly might work for certain use cases (and indeed appears to do so), many of the use cases that Kafka is necessary for would end up being just as complicated to setup Redis to support.

I think this is largely a rephrasing of one of the findings of dealing with NoSQL vs. Relational DBs, which is that for a subset of problems relational DBs have been used to solve in the past, NoSQLs are perfectly capable of replacing them, but not every problem a relational DB handles can be handled by a NoSQL without investing significant time and effort layering more complex systems on top, at which point you've basically implemented a poorly optimized ad-hoc relational DB. In this case, Redis, with the new stream type is capable of handling a subset of problems that have previously required Kafka to solve, but it isn't itself a replacement for Kafka in all situations since there are several important features of Kafka that aren't available in Redis.

That's at least partially the fault of that particular language getting cute with their naming and not considering the impact that has a on trying to disambiguate things without having to introduce further context. Ruby isn't the only one who commits that particular sin (looking at you Chef). Java arguably commits the same sin with regard to the core language, but considering how rarely "java" is used on its own in reference to the coffee based beverage that's fairly harmless. Moral of the story, stop getting cute with the names of your stuff and naming a bunch of different tools/concepts/frameworks with ambiguous names. If you must do so at least use some clever portmanteaus and don't just straight up steal other words that already have specific completely unrelated meanings.

grumble grumble chef knife, chef cookbook, chef recipe, chef cucumber incoherent mumbling

Well, it's kind of a mix of NIH and this weird cargo-cultish idea that every API needs some kind of wrapper around it. In the past if anyone wanted to use basically any library it was a major battle to get permission to do so, so a lot of code ended up being written to do things that were already provided in fairly standard libraries which is where the NIH comes in. On top of that, they then insisted on using wrapper libraries that exposed essentially the same API as the libraries they did bring in (and then never updated ever again before finally cutting support for their wrappers). The infuriating thing is that the wrappers were both tightly coupled to the underlying library in a way that makes them useless from abstracting from the underlying library, but also differed ever so slightly so that ripping them out and using the underlying library is still a major refactoring. The major impetus for the refactoring we're currently doing is that all these wrappers formed an interlocked set of dependencies on very specific versions of the underlying libraries and all of it was starting to suffer from bit-rot, with many of the libraries being stuck on versions that had been EOLed or were otherwise many years behind in updates. The worst one I can think of off the top of my head was one library that was pinned to a version from 2006 (and was still actively maintained with current releases from this year, so this wasn't even a deprecated library, just the wrapper was preventing it from being updated).

My current job is mostly about eliminating code. We've got a massive code base that suffered severely from "not invented here" syndrome where nearly everything was implemented as a custom wrapper around some other library to avoid "vendor lock in", nevermind that the wrapper exposed essentially the exact same API which was so library specific that any attempt to replace it would basically amount to a total rewrite. I and my fellow devs have spent the last few months ripping out all the unnecessary wrappers all over the code base, updating library versions, and in many case eliminating entire trees of dependencies that are simply no longer needed. We're still in the middle of the effort, but by the time we're done I'm estimating we'll have cut our startup times to 1/10th what they are now as well as eliminated 75% of the dependencies across our projects.

Well, mostly disinterested in that it's really just a more precise measurement. The "breakthrough" in this case is a ridiculously precise measurement, which is very impressive, and is a huge step forward for particle physics as a science because it opens the door to measure even more stuff, but in this particular case it hasn't contributed anything "new" in terms of data.

There's a famous quote out there that goes something like 'the most exciting words in science aren't "Eureka", they're "that's odd"', and I feel that's highly applicable in this case. There's no "that's odd" event here, everything is exactly as expected, it all worked perfectly and produced exactly the result that was expected. That's great for affirming that all our theories are correct, and as I said this is a breakthrough in the quality of measurements we can achieve, but it's not a new mystery to explore, or an unexpected result that we can use to refine or develop new theories. Basically everything we didn't know before this experiment we still don't know, and we don't have any new data points except for having eliminated an area of uncertainty that new interesting data might have been hiding in.

alternate TL;DR: Science was done, no new data was generated that couldn't have been predicted from existing laws, existing mysteries remain.

Basically this is the "boring" science, not the exciting "hmm, that's odd" science. It's very important science of course, the sort that you need for science to actually work, but it is rather boring from the perspective of someone outside looking in on the process.

C is incredibly permissive with regard to its types which are themselves very anemic. With the exception of the numeric primitives, C really only has a single type, the pointer, everything else is just syntactic sugar for various forms of pointer arithmetic. For instance arrays in C are just a shortcut for some pointer plus an offset multiplied by a constant determined at compile time based on what you've claimed is the underlying struct or primitive of the array. Importantly C is perfectly happy to take any random pointer into arbitrary memory and allow you to map any set of offsets into it. It's worth looking at for instance Rust that at least in theory allows the same thing to be done, but only by explicitly opting out of static checks via unsafe declarations. In normal safe code Rust will statically verify that a given reference (pointer more or less) is in fact referring to the type you're code is expecting it to, rather than the C approach of simply assuming the program is correct. Looked at another way, as far as the C compiler is concerned nearly everything is a pointer, and one kind of pointer is entirely exchangeable with another kind of pointer (with at most a cast being required, but probably not even that if it's the entirely too common case of being a void pointer). This is in contrast to nearly every other statically typed language that will either at compile or runtime verify that any given reference is the appropriate type before dereferencing it. C++ nominally at least has a more powerful type system, but since it was designed (in theory at least) as a superset of C, C's permissivity blows a giant gaping hole in its type system.

> I definitely had much more null pointer exceptions on java than typing errors on Python

Null pointers are a type error. The fact that several nominally "statically" typed languages don't differentiate between nullable and non-nullable types is a significant source of failure in their type systems. Using a modern language that properly identifies nullable values as a distinct type from non-nullable ones goes a long way towards eliminating a whole host of problems. It will be interesting to see what things look like in 10 years or so once Rust has had time to really displace a significant portion of the C and C++ code in the wild, and hopefully Kotlin has killed off Java (and if we're really lucky Typescript has done the same more or less with Javascript).

More or less your first point, the rate of growth is so low, that over short term it's effectively zero sum.

Something else to consider is that in your example of "for free" wealth creation you're not actually getting any of that for free, that's a form of wealth transformation or transfer. Let me elaborate on that point using each of your examples. I'll start with mining as that's the simplest, in that case you're taking a natural resource (which is finite) and extracting it and refining it. You're having to pay your workers (and/or buy and maintain machines) in order to do so, so in part your redistributing the companies wealth to the workers and service providers your company does business with. In exchange you receive raw and/or processed minerals/metals. That might seem like wealth creation but it's really transformation, you've reduced the value of the land you extracted the material from and converted it into a transportable form. The value of that material might seem to be more, but that's only because you've invested value in extracting it, in other words you're passing on your cost of doing business. You haven't added value, the value was already there, you've simply converted it and invested some of your companies value into it, so when you sell it you're simply converting one form of wealth into another, you're converting the wealth of that processed material into cash wealth.

The situation with growing crops is similar, although part of what is being invested there is time. You might think, "well, time is infinite, there's always more time", but each persons time is finite and it has value, even if only to that person (opportunity cost), so once again you're doing a wealth transformation, you're transforming those workers time into money, and ground, seed, fertilizer, water, and sun into crops. When you sell those crops you're once again recouping your cost of doing business. Wealth hasn't been created from nothing, it was transferred and concentrated from a variety of sources. You might think, "well, what about the workers time, that's new wealth", only it isn't, there was a cost involved in those workers upbringing and living, so that's once again just a form of wealth transfer and transformation. Truly the only free wealth in the entire thing is the sun, although even that isn't infinite, even if it is free from the perspective of anyone on Earth (it might be more accurate to say it's wasted/destroyed if you don't use it). Ultimately there is no free lunch, entropy always wins.

Software is the most complicated one, as there's zero unit costs associated with it, but substantial development costs. Once again though, you're looking at wealth transformation/transfer. In the case of software you're transferring/transforming the developers, QA, and other workers personal knowledge and time into software. Similar to the workers in the previous example they've invested time and money into improving their knowledge and living, so you're really paying them for them to recoup their losses (wealth transfer) and then when you sell the software you're simply passing those expenses on to your customers.

Ultimately it's all about wealth transformation and transfer. There is finite natural wealth, it existed before humanity, and if humans vanished tomorrow it would continue to exist. Economies are mostly about taking the existing wealth and distributing, concentrating, and transforming it into forms that are more convenient for people. When you get down to it, the unit cost of a good is really it's intrinsic value, it's a form of wealth transformation. Profit margins on the other hand, are wealth transfer, you're transferring wealth from the purchaser to yourself. No value is actually being created. New wealth only comes from discovering new resources. Want to create wealth now? Do like Elon Musk and others are doing and take a look at asteroid mining.

That also implies that demand for other products has fallen, so that's just wealth redistribution (because you're taking a larger share of their wallet).

It isn't a question of actual dollars in circulation, you can always print more after all, it's a question of total economic value. All goods in circulation in the U.S. have a finite value, and it definitely is a zero sum game. You can add more goods and therefore value, but that can only happen at a certain rate (this would be tied into population growth, employment rate, and profit margins among other things). There are also close ties with median income as the value of goods tends to be tied directly to wealth distribution. Ultimately at any given time there is a finite amount of "wealth" to go around, if one person gets a bigger slice, then that means someone else has to take a smaller slice. People don't want to be millionaires because they have some unhealthy attraction to U.S. currency, they want to be millionaires because of the goods and services that they can trade that money for (or in many cases because they can use it for rent seeking to generate unearned income). The actual amount of currency in question is irrelevant, it's a question of access to those goods and services, and those goods and services are finite, therefore wealth is finite.

I find an interesting parallel with hill-climbing and local optima. In your example, the reason everyone isn't a millionaire is mostly to do with the fact that that's a very noisy problem space, there are far far too many random variables at play, not to mention there's a finite supply of money, it's literally impossible for everyone to be a millionaire (well, you could inflate the currency to the point where a million dollars is nearly worthless, but that's just playing semantic games).

To me, one of the big takeaways here is that it's important not to be so hyper-focused on the local problem space that you overlook potentially better solutions and end up at a local optimum to your overall detriment.

As for the rest of the article, it's mostly hand-wavy garbage.