orclev

Can do both. Destroy the company, but also go after those responsible. Anyone who knew about the situation but didn't make their supervisor(s) aware is personally liable for damages. Anyone on the board or C-Suite that was aware and either did nothing or didn't notify regulators is also personally liable. In both cases if anyone died as a result the companies actions they should be tried for manslaughter.

Corporate capital punishment, the company gets seized it's patents and copyrights made public domain, and any other assets it has sold to the highest bidder and those profits used to compensate the victims.

Why not? Nothing in the GPL says you need to certify your code for commercial usage in the EU.

Edit: In fact, reading the GPL it looks like it might implicitly already preclude usage in the EU under this law. There's this section right here:

    11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
    12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Does OW2 even run on the SteamDeck? Checking ProtonDB says it's unknown compatibility, but generally competitive PvP games struggle due to their highly intrusive DRM/anti-cheat that wants root kit level access.

Don't need to actually block EU downloads, just state that no open source software is certified for commercial usage in the EU. Any company that ignores that is now in violation of this law and that's their problem. The EU will need to decide if they want to allow their businesses to continue benefiting from open source software or fix this law.

The interesting question is really what happens when commercial software companies outside the EU that use open source libraries decide they don't want to deal with this headache _also_ start refusing to certify their software for use in the EU and stop doing business there.

The best one I've seen is jOOQ, although there are some caveats. There are a number of advantages and a few disadvantages to using a query builder. On the positive side you have:

1) Implementation agnostic queries. For better or worse SQL is a VERY loose standard with tons of little quirks for each underlying DB. Using a query builder lets you write a standardized syntax that then gets translated to match the quirks of the actual SQL implementation for you. This _somewhat_ although not entirely insulates you from the underlying implementations details.

2) Works with existing language tooling. Using the actual language you can take advantage of things like intellisense and syntax highlighting to write code and spot typos. In a more traditional SQL client you'll be embedding your queries inside of Strings and in the worst case constructing ad-hoc queries by appending strings together.

3) Related to point 2, you get compile time checks that your queries are well formed and that your types make sense. This is where the first major problems also come in, but more on that later.

4) Possible compile time optimization of your queries. I'm not aware of any builder that does this, but in theory just like language compilers run optimization passes over the AST generated from your code, you could in theory optimize the query that results from your builders AST (this could possibly even be done at compile time).

And now for the cons.

1) Dependent on the query builder to support every weird quirk and advanced feature, and raises the problem of what to do when a feature is used in a query that isn't supported by the underlying implementation. If you want to use some slightly obscure feature supported by your particular DB but isn't supported by the query builder, you might just be SOL.

2) Compile time headaches due to either generating or validating code. Often times these tools work best when at compile time they can connect to your actual DB to read its schema and either generate code (such as enums of tables and columns) or to validate queries (E.G. checking that a varchar column is being treated as a string and not an int). If you have a conveniently accessible local instance or dev env this might not be a problem, but then you often also need to find a solution for your CICD server. This also says nothing about generated code which is it's own set of headaches.

3) Yet another DSL to learn. You're now no longer writing SQL, but instead something SQL adjacent that has been projected onto another language in a no doubt imperfect fashion. You're now needing to use knowledge of both SQL and your language of choice simultaneously in order to write queries. In theory the compile time checks and language support might make this a wash, but it could become relevant if you run into some weird edge cases and need to debug.

As for things I'd wish for in an ideal query builder, I think it's VERY important to provide options to avoid needing to establish DB connections at compile time, while also still providing the advantages that often provides. Being able to E.G. point the tools at files checked into version control containing your schema DDL and validate queries or generate code based on that would be a great feature to have.

Beyond that providing adequate escape hatches for unusual features when building queries is also important. There should be a way to invoke arbitrary functions or chunks of raw SQL outside of the confines of the query DSL (with the understandable restriction that query checking of such chunks will be minimal at best).

That's interesting, it didn't used to be linear, particularly on the very large instances. Oddly when looking at the prices for RHEL those are much closer to what all the prices used to look like (I hadn't actually looked at AWS pricing in a few years). I wonder if AWSes virtualization tech has just reached the point now where all processing is effectively fungible and it's all really just executing on clusters of mid-range CPUs no matter how large your virtual server is.

It's because Erlang abstracts the difference between distributed and centralized services. In Erlang everything is message passing, and Erlang doesn't much care if the components passing messages are running on the same server or multiple ones in a DC, it will route the messages either way. In many ways Erlang is the ultimate micro-service, to the point where the entire language is built around it.

Perhaps I should have said he was a manager on the Excel team.

Pretty sure Amazons entire backend is C++. Hard to get much bigger than that.

Eh, not sure that follows. Here's the thing, costs aren't linear. If you do what AWS does and create some artificial "compute units" as a sort of fungible measure of processing power, what you'll find is that the sweet spot for price per compute unit is a medium power system. The current mid-range processors tend to be slightly more expensive than the low-end processors, but significantly cheaper than the high-end processors.

So, hypothetically, lets say you can get one of 4 processors, a low end one that gives you 75 units for $80, a mid-range processor that gives you 100 units for $100, a high-end processor that gives you 125 units for $150, and the top of the line processor that gives you 150 units for $300. If you normalize those costs, your 4 processors get price-per-compute values of $1.01, $1, $1.20, and $2. The best value is at the $1 per compute unit price point of the $100 processor. Logically if you need 150 units of compute power you have 2 choices, you can use 2 $100 processors, or 1 $300 processor. Clearly the better option is the 2 $100 processor. This would be scaling out. In the case of what SO did though, they took that off the table, because their formula isn't just the cost of the processor (ignoring related things like RAM and storage), but also includes a per-instance license cost. Their math ends up looking more like $100 CPU + $150 windows license times 2 totaling to $500, vs, $300 CPU + $150 windows license times 1, totaling to $450, which ends up making the more expensive processor the cheaper option in terms of total costs.

It's important to remember Joel Spolsky, one of the founders of stackoverflow is an old school Microsoft guy that managed the Excel team before starting his own company. He has always been a bit of a Microsoft fanboy, and used to advocate a lot for VB as a serious language back before it got swallowed by .Net and turned into a less powerful syntax for C#. The fact they chose C# isn't surprising at all given that. It actually would have been far more surprising to see them pick anything but C#.

I think the previous poster was a bit off the mark though. The language performance wasn't really the issue there, rather it's the fact that they picked a language that at the time really only ran on Windows, and as a consequence they were forced into running their web servers on Windows. That choice then forces them to scale up rather than out since each instance has license costs attached to it. For most companies running on Linux, it's trivial to scale out since your only costs are the compute cost (or the hardware cost in a non-cloud model), where as it tends to be far more expensive to scale up as more powerful hardware tends more towards geometric increases rather than linear. These days the choice of C# wouldn't be such a big issue as .Net core can easily run on Linux servers, but back in the 2000s using C# was putting a pretty big albatross around your neck by way of Windows licenses.

Considering the shift to AMD from Intel that has happened over the last couple years it will be interesting to see if we'll see AMD as more of a priority target in the future. AMD has certainly been leading in sales in most demographics for the last year or two, and there's little sign of Intel closing that gap. AMD has even made some moves recently that indicate some desire to chase Intel out of the lead in the few niches they still control, like the x86 low power/cost device market that has been dominated by atom/celeron.

There's an important difference between using something because it's popular, and using something because it's a standard designed for your problem. For something simple like just sending some numbers across the wire XML is massive overkill (as an aside, there's actually very little XML is a good solution to). CSV, TSV, JSON arrays, one of dozens of serialization formats, or even just a simple EOL separated value like you proposed are all both standardized and very simple solutions to the problem. On the other hand, had they proposed inventing some new binary serialization protocol and using that to transmit the numbers, that would be even worse than using XML.

You should always pick the simplest solution to the problem that meets all your requirements, but when considering solutions you should favor standards compliant solutions. A common example is date formats. Lots of places roll their own date format string when sending dates, but using ISO-8601 will save you (and your clients) so many headaches in the long run.

Honestly for your example, not knowing all the details I can't say for sure if a EOL separated value is a good solution, but based on just the description I probably would have gone with a CSV, or possibly a JSON array. I definitely would not have used XML (dear god, why would anyone pick XML in this day and age?), although if they were concerned about needing to add more data down the line I could maybe see an argument for something a bit more involved than a CSV.

L4 uses a similar model, and the last ~20 years of research around L4 has mostly focused on improving IPC performance and security. The core abstraction is a mechanism to control message passing between apps via routing through light weight kernel invocations (which is indeed practically the only thing the kernel does, it being a microkernel architecture).

Memory access is enforced, although not technically via the kernel. Rather at boot time the kernel owns all memory, then during init it slices off all the memory it doesn't need for itself and passes it to a user space memory service, and thereafter all memory requests get routed through that process. L4 uses a security model where permissions (including resource access) and their derivatives can be passed from one process to another. Using that system the memory manager process can slice off chunks of its memory and delegate access to those chunks to other processes.

A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you. In a similar vein, a well known standard format (or encoding) will always be a better choice than some ad-hoc format you create yourself because not only will that standard have encountered and dealt with problems you haven't even considered, but there are also likely to be a plethora of libraries, frameworks, and tools that support that format, where as if you create something yourself you end up needing to create anything you need.

Your time is generally better spent working on solving your core problem rather than the dozens of ancillary problems that end up needing to be solved along the way (particularly where a whole bunch of other people have spent a whole bunch of time already solving those problems).

The problem is that security questions are fundamentally flawed. Most of them are easily guessable with a little bit of research, and because they can often be used to bypass your password they're effectively a backdoor into your account. You're generally better off using them as either a backup password (that is, not guessable even given knowledge about you), or simply not using them at all. If you forgot your password then reset it via your e-mail account. In short, don't use security questions, they're fundamentally broken.

The term dark matter itself is kind of misleading in the first place. The math in general relativity just doesn't add up when applied to certain observations. They've essentially gotten 2 + 2 = 5. In order to fix that they just assume that one of those 2's was actually a 3 somehow, and the extra 1 it picked up got labelled as dark matter. In other words, dark matter is just a term for some missing numbers somewhere in the calculation. Based on the different places where the extra numbers might be included they think it's something with mass, but really that's just a guess based on the existing formula and the changes that would be necessary to make it match the observation.

So, first thing, I'm not a astrophysicist nor even a physicist of any type, so I might be misunderstanding things here, but this is how I interpret all this. Hopefully if I've gotten something significantly wrong someone will correct it.

General Relativity matches observations to a point. The issue is that it stops matching observations once you reach galactic scales. In order to explain why that doesn't work you need to start hand waving, and the start of that is dark matter. MOND was thought up not so much as an alternative to General Relativity but as an alternative to dark matter. It tweaks some of the math used in General Relativity to assume that gravity behaves differently at different levels. Basically once you have a strong enough gravitational field it behaves like the gravity we know, but until you hit that point its effects diminish at a different rate. Doing that explains why galaxies behave like they do. For the bulk of the galaxy gravity is strong enough that it behaves exactly like General Relativity says it should, but out near the edges of the galaxy gravity has grown weak enough that it behaves differently. It's sort of hand wavy and leaves a bit of a bad taste in the mouth since there's no real explanation of why gravity should behave that way. On the other hand it doesn't require some phantom matter that we have no observational data to back up.

Either theory falls far short, and both of them require a lot of fudging around the edges to align with galactic scale observations, although MOND once you get past the arbitrary change to gravity seems to require less hand waving. Importantly for the linked paper it also seems to line up with the proposed theory and predict the kind of void the paper is predicated on which would be a strong point in favor of MOND.

Of key point to the proposed theory, General Relativity predicts that in the first moments after the big bang that the universe was essentially uniform, that everything spread out more or less evenly, and it wasn't until much later when things started to form the likes of planets and stars that we started seeing significant variation in matter distribution of the universe. MOND on the other hand allows for variation in that initial expansion. That's important for the paper because there simply isn't enough time in the General Relativity model to explain a void the size that their theory predicts would be necessary to form. MOND allowing for more variability early on on the other hand does allow enough time that a void of the necessary size could exist.

Basically General Relativity on its own doesn't work for things galaxy size and bigger. MOND on its own doesn't work at galactic cluster levels and above. The theory proposed in the paper could explain the discrepancy we see in the rate of expansion of the universe, but doesn't seem to be possible under General Relativity, but is possible under MOND. Both General Relativity and MOND rely on the presence of things not observed yet in order to match with our observations once you scale things back far enough, and neither on its own can explain why the universe seems to be expanding faster than they predict it should. The paper proposes one theory for that, but it's only possible with MOND.

Not sure honestly. That might have something to do with the vHDM theory mentioned in the paper. I didn't really follow a lot of it, but I think (major grain of salt here) it's saying that that theory predicts some very light neutrinos exist and tend to collect inside of galactic clusters, but not galaxies themselves and that it's those neutrinos that make up the missing mass at universal scales that general relativity explains using dark matter.

Either case seems pretty hand wavy honestly. When it comes to galaxy and universe level physics it all seems pretty weak compared to the sort of particle physics and classical physics that we can actually measure and test on Earth. It's all just a bunch of theoretical math with relatively few actual measurements to pin it all down. I don't think we're anywhere near having a solid theory of the universe so it's mostly an exercise in trying to prove which theory is the least wrong at this point, rather than which one is correct.

Another ELI5 by someone not at all qualified to understand this stuff (I.E. a layman).

We know from measurements of the leftover energy (CMB) approximately how long ago the big bang happened, and how fast it appears to be expanding. Our most favored model of the universes physics, General Relativity makes certain predictions that mostly match up with reality up until you get to galaxy scales at which point they start to diverge. In order for our measurements to work under General Relativity our galaxies need to be more massive than they appear to be based on all the stuff we can actually see in them. This needed excess mass is called dark matter, but even with dark matter the universe appears to be expanding faster than it should. The theory proposed in the paper is that the universe as whole isn't actually expanding faster, but due to a quirk of where we are in the universe it only looks like it is when we look at nearby galaxies. Unfortunately for that to be true we would need to be in a void in the structure of the universe which General Relativity predicts shouldn't be possible.

An alternative theory of universal physics exists called MOND. MOND is similar to General Relativity, but rather than solving the problem at the galaxy scale through theoretical dark matter, it instead just assumes that gravity works differently once you reach a certain cutoff point. This aligns with observations of actual galaxies (not entirely unsurprisingly because the cutoff point was chosen in order to align with those observations) without needing dark matter to exist. From the perspective of the paper there's another nice property of MOND which is that simulations based on it allow for the kind of void to form that the paper predicts would be necessary to explain the locally observed expansion.

Basically, General Relativity can't explain how fast galaxies spin without Dark Matter, nor how fast the universe appears to be expanding. MOND combined with our galaxy being in the middle of a big void can explain both. Both theories, General Relativity and MOND require a certain amount of hand waving in order to align with reality. MOND requires a bit less but is highly suspect because it's solution is basically "gravity just acts different sometimes" which is suspiciously close to "it's that way because it is".

As for the actual math involved in all of this, beats me, we'll need to wait for someone who's actually in this field to look it over and explain what if anything is wrong with it all.

That's because there isn't one. Fish of any kind is generally considered to be seafood.

More generally labeled as Krab.

Because game developers mostly don't pick the backend, game engine developers do. The vast majority of game developers pick a game engine and that drives most of their other technical decisions. There are really only a dozen game engines that have enough market share to matter, and a decent chunk of the biggest ones were built on top of DX for various reasons. OpenGL, while a great concept, was a fairly flawed execution for quite a while (its gotten a lot better in the last 10 years or so), so I can at least partially understand why in the past someone who doesn't care at all about cross-platform support might have steered clear of it.

I certainly hope it doesn't come to that. Servo was really starting to show serious improvements in both memory usage and speed relative to Gecko and Webkit. It would be a shame to see Firefox devolve into just another rebranded Webkit browser, particularly since everyone loses when things devolve to a monoculture.

You're solution is the ideal one and safest, although in the interest of maximum flexibility since the goal here seems more documentative than prescriptive, it could also be as simple as creating a type alias. In C for example a simple `#define UnitInterval float`, and then actual usage would be `function FuncName(UnitInterval accuracy)`. That accomplishes conveying both the meaning of the value (it represents accuracy) and the valid value range (assuming of course that UnitInterval is understood to be a float in the range of 0 to 1).

Having proper compile time (or runtime if compile time isn't feasible) checks is of course the better solution, but not always practical either because of lack of support in the desired language, or rarely because of performance considerations.

It's a question of what is meant by the term censorship. In the strictest sense, moderation and censorship are very often the same thing. If for instance, I post something terrible in a comment on here, and the administration of HN deletes that comment, then that's censorship.

However, when most people talk about censorship they're using it not in the strict sense, but rather as a shorthand for someone violating their first amendment right. In this case this is really only a crime when it's a government entity doing it, although people don't typically differentiate between the government and any large organization, which technically are legally allowed to censor you on their platform or property.

There's a larger discussion that needs to happen with regards to censorship. There are two extremes at play here, on the one hand there's the absolute freedom stance of literally nothing censored (only example I can think of for this is maybe the dark web, but really everyone censors if only a little), even shouting fire in a crowded theater or posting child pornography. On the other extreme is the absolute censorship of someplace like China, where only permitted thoughts and expressions can be posted. The US and most of the rest of the world tends to fall somewhere in the middle.

The big struggle right now is that everyone has recognized that there's clearly some kind of problem. We're seeing unprecedented levels of misinformation, and a frankly weaponization of social media both for profit, and for international politics. I don't know that anyone has a good solution for how to address that problem, but the pendulum seems to be swinging towards a more censorship focused response.

That chart is s great example of exactly what I'm talking about. Look at that 95th percentile line. It's LEFT of the center. 95% of the population is making less than HALF of the top earners.

Median is just the arbitrary mid point between the two extremes, that doesn't actually mean anything useful to the average person. If you picked someone at random from the subset of the US population that reports an income (presumably the working population) and asked them what their income is, the most likely answer is the mode value, or in 2014 about $22,000. That's reality. That's why that is important.

The median income ($53,000) is literally pointless except as yet another indicator of how unbalanced the economy is. If the economy was perfectly balanced the median and mean would be the same, but they're nowhere near that. The median was $53,000, while the mean was $75,000. An incredibly large chunk of the US is making significantly less than a handful of massive earners. And that's not even factoring in all the dirty tricks that the richest use to hide their wealth like offshoring bank accounts and shifting most of their assets into capital gains.

My point was that the mode income, that is the income reported by the largest number of people was incredibly low. You claim that's because there are a bunch of people that don't really need/want to work, so they don't make much. That implies that that group represents the majority of the working population (in order to be the mode income). You're point might have been correct if we were talking about the mean income being very low, but in this case it's exactly the opposite.