danvet

42 billions total now, the 32 billions just announced is on top of the 10 billions already put aside last week.

And yes with these measures essentially any income is now assured: Salaries, salaries of SMB owners (normally excluded from unemployement benefits for obvious reasons), hourly workers, limited contracts, internships/apprenticeships, self-employed (i.e. without being employed by an LLC or something else like that) business like artists. Also daily stop-gap money if you have to stay home for more than a few days to figure out how to take care of your homeschooled kids.

Plus like 20 billions in credit guarantees for small businesses to avoid a cash flow squeeze.

All measures use existing infrastructure for paymenet (commandeering the banks for the cash flow squeeze credits) to guarantee the money has arrived by end of the month, latest. And that it will continue to flow, like regular pay check.

At first I thought like "hey Carmel doesn't look so bad". Then I realized all the grey stuff is parking lots, not houses.

There's no one keeping track of that as far as I know, but the group picture of kernel maintainers (just picked the first one google brought up) is fairly informative on your questions.

https://lwn.net/Articles/705244/

I wouldn't say that the kernel community is a success storie in this regard ...

The OpenGL threading model is completely screwed up. You essentially have a global lock per GL context, which means you're restricted to 1 thread for issuing rendering. And in GL a context is for everything, including shaders, texture states, you can't even reasonable do uploads of new scene data in a separate thread.

Vulkan fixes this big time, by allowing apps to construct GPU workloads for a single GPU in parallel. Only the final submission step (which is supposed to be very low overhead if the driver design is decent) is single-threaded per GPU context. And even for that Vulkan is better: It allows you to allocate different contexts for separate engines (e.g. rendering vs. compute vs. copy engine for data up/download to/from the GPU vram).

The lower CPU overhead is just the icing on the cake, the real deal is that Vulkan fixed the threading/locking model.

I commented a summary on the phoronix forums already, copypasting here. I'm the good cop in the good cop/bad coop game Dave&I have been playing in this. Maybe this helps clear up some of the confusion and anger here.

This is me talking with my community hat on (not my Intel maintainer hat), and with that hat on my overall goal is always to build a strong community so that in the future open source gfx wins everywhere, and everyone can have good drivers with source-code. Anyway:

- "Why not merge through staging?" Staging is a ghetto, separate from the main dri-devel discussions. We've merged a few drivers through staging, it's a pain, and if your goal is to build a strong cross-vendor community and foster good collaboration between different teams to share code and bugfixes and ideas then staging is fail. We've merged about 20 atomic modeset drivers in the past 2 years, non of them went through staging.

- "Typing code twice doesn't make sense, why do you reject this?" Agreed, but there's fundamentally two ways to share code in drivers. One is you add a masive HAL to abstract away the differences between all the places you want your driver to run in. The other is that you build a helper library that programs different parts of your hw, and then you have a (fairly minimal) OS-specific piece of glue that binds it together in a way that's best for each OS. Simplifying things of course here, but the big lesson in Linux device drivers (not just drm) is that HAL is pain, and the little bit of additional unshared code that the helper library code requires gives you massive benefits. Upstream doesn't ask AMD to not share code, it's only the specific code sharing design that DAL/DC implements which isn't good.

- "Why do you expect perfect code before merging?" We don't, I think compard to most other parts in the kernel DRM is rather lenient in accepting good enough code - we know that somewhat bad code today is much more useful than perfect code 2 years down the road, simply because in 2 years no one gives a shit about your outdated gpu any more. But the goal is always to make the community stronger, and like Dave explains in his follow up, merging code that hurts effective collaboration is likely an overall (for the community, not individual vendors) loss and not worth it.

- "Why not fix up post-merge?" Perfectly reasonable plan, and often what we do. See above for why we tend to except not-yet-perfect code rather often. But doing that only makes sense when thing will move forward soon&fast, and for better or worse the DAL team is hidden behind that massive abstraction layer. And I've seen a lot of these, and if there's not massive pressure to fix up th problem it tends to get postponed forever since demidlayering a driver or subsystem is very hard work. We have some midlayer/abstraction layer issues dating back from the first drm drivers 15 years ago in the drm core, and it took over 5 years to clean up that mess. For a grand total of about 10k lines of code. Merging DAL as-is pretty much guarantees it'll never get fixed until the driver is forked once more.

- "Why don't you just talk and reach some sort of agreement?" There's lots of talking going on, it's just that most of it happens in private because things are complicated, and it's never easy to do such big course correction with big projects like AMD's DAL/DC efforts.

- "Why do you open source hippies hate AMD so much?" We don't, everyone wants to get AMD on board with upstream and be able to treat open-source gfx drivers as a first class citizen within AMD (stuff like using it to validate and power-on hardware is what will make the difference between "Linux kinda runs" and "Linux runs as good or better than any other OS"). But doing things the open source way is completely different from how companies tend to do things traditinoally (note: just different, not better or worse!), and if you drag lots of engineers and teams and managers into upstream the learning experience tends to be painful for everyone and take years. We'll all get there eventually, but it's not going to happen in a few days. It's just unfortunate that things are a bit ugly while that's going on, but looking at any other company that tries to do large-scale open-source efforts, especially hw teams, it's the same story, e.g. see what IBM is trying to pull off with open power.

Hope that sheds some more light onto all this and calms everyone down ;-)

Complying or not complying to a foreing judges orders is a pretty common problem for any multinational company. Even if they have local presensence, the thing requested (data, object, whatever) might be somewhere else. And simply fetching it across a border on a foreign judges order can get you into trouble for "aiding a foreign power" and stuff like that.

It's worse that most local judges simple don't know that there's even a problem, and even if that'a clear to them, the judge most likely has 0 experience in making a successful request to the foreign state. And since all bureaucrats if the request isn't perfect it falls through the cracks. So often (at least if you're locally present) your laywers will need to help the judge to draft and push such a request through.

Long story short: These jurisdictional issues are not at all US specific, it's everywhere. Sovereign states just don't like it all over if their citizens and companies do stuff within their borders under orders of a foreign state.

PSR on skl is still disabled by default, because there's some corner cases we haven't fixed yet. In case you wonder: more recent platforms shut down more of the chip in PSR, and we haven't yet wired up the power management calls to wake it up again if we need it for those cases. Hopefully addressed in 4.7. Meanwhile you can enable it manually with i915.enable_psr=1 on the kernel cmdline and see whether it works in your case.

Open source gpu drivers on Linux clear all allocations the kernel driver hands to userspace. And where it exists, different clients are also isolated from each another through the gpu MMU. On top of that all drivers guarantee that no gpu client can escape the gpu sandbox to general system memory, and on chips where hw engineers didn't provision any useful hw support to enforce this it is done by pretty costly gpu command stream parsing in the kernel.

You can't opt out of these security features on upstream/open source linux drivers either.

Now of course this won't insulate different tabs in chrome since chrome uses just one process for all 3d rendering. But GL_ARB_robusteness guarantees plus webgl requiring that you clear textures before handing them to webpages means that should work too. On top of that webgl uses gl contexts (if available), and on most hw/driver combos that support gpu MMUs even different gl contexts from the same process are isolated.

This really is a big problem with binary drivers, and has been known for years.

To all the armchair domain admins commenting here: It's a single-letter domain in one of the traditional non-country TLDs. It only exists because it was grandfathered in in 1993 [1] I'm pretty sure no one here ever dealed with such a situation ever. If you try to change anything in its registration without supplying it in a legally watertight package delivered by lawyers nothing at all happens, not even extending the registration as the non-owner. Just check the whois entry and look up the various ICANN domain status codes.

1: https://en.wikipedia.org/wiki/Single-letter_second-level_dom...

It's used to teach CS undergrads programming basics at ETH Zürich. At least a few years ago ...

Entropy _is_ statistics ... it's just another measure for the probability of a given state.

Iirc DVD subtitles are actually a pre-rendered overlay stream. YUV (with uv subsampling) works great for pictures, not so much for text (and has only ever the original DVD resolution and hence fails at upscaling). VLC does indeed grab subtitles from the text and renders them crispy in the screen resolution.

In the linux kernel community, you'd get shot for this attitude. Now granted there are not many projects out there with this scale and complexity, but still: A one-liner commit-message for anything else than a trivial refactor is stupid. You want motivation for that change, references to bug reports and analysis of the problem (and potentially other ways to solve it and why they were rejected) in there.

And you absolutely don't want all that crap in the source code, because it routinely happens that a few lines of diff require a few paragraphs of commit message to explain why this is the right thing to do.

And browsing that massive amount of information with recursive git blame (or gitk's equivalent) and the more specialized history digging functions is easy. At least much easier than browsing through the equivalent embedded in source files, and I've seen the latter.

One thing you're right, though: Writing concise one-line summaries of a commit (which is the only thing a git shortlog shows) is a must.

This.

Math is a tool (and sometimes abused for pure pleasure, 200 years later applied to make hard crypto work). If your definition doesn't make sense for the application, fix your definition and get over it.

Another example I've recently often bitched about in discussions is modern measure theory and its application to probability calculations. People just don't get the concept of theorytically possible event, but probability 0, i.e. ignore this. But without Lebesgue integration L_p function spaces are not complete and an awful lot of stuff stops to work properly. Among them essentially all of modern physics.

The sane approach is to get over the "this doesn't make intuitive sense" bitchering and just use defintions to derive useful results. And after a few years of playing around with stuff and applying the un-intuitive definition, it's becoming intuitive ;-)

Highly unlikely that three runs of the same test are fully independant, i.e. they might match all on the same antibody which is similar to an HIV one but not due to a HIV. You likely only prevent operation goof-ups like "oops, spilled a bit of blood from the needle of my bro here ..." (or something less fancy and more likely).

Which is why in practice you run a different test to confirm results.

Exactly. All this massive discussions about creating new money somehow ingnores the elephant in the room: If banks with too much leverage would actually be able to default people will suddenly notice the problem and check their bank's reserves before opening a deposit or something like that (in historical timeframes, i.e. years ...).

Now the problem is obviously that everyone who went along for the ride, hoping for the best will go bust, too. Among them the top 0.1% (or at least a large part, you need to substract the Warren Buffet type). Obviously the rich and powerful don't like becoming poor and deprived of power, so the bailout themselves via the gov't/fed.

And as a strawmen they set up the crumbling 401k savings of the 99.9% normals.

An aside: I seriously wonder what would have happend if the gov't would have continued to let banks default. I don't think it'd be much worse than the Marshall plan for Germany with it's complete reset of the (liquid) wealth after WW2. And that went really well. And for a bit of fairness, resetting the clock every 80 (because people tend to forget the last utter economic catastrophe) probably won't hurt.

In my experience people tend to be zealots only in certain very specific areas and quite reasonable everywhere else. I.e. your proposal's running the serious risk of muting and awful loot of folks here on hn just because the might get a bit hot-tempered on specific subjects.

You've made my day. This is one of the tricks to I often forget about again but just smile upon reencountering.

Step 1: Transform to the eigenbasis of your operator. Step 2: Enjoy the beaty.

The problem with that approach is that tuning it is hard, i.e. it's rather harder to ensure that the knob somewhat linearly adjust from "not toasted" to "black" and the useable control range isn't just a tiny part at one end of the full range.

Luckily changing software doesn't (usually) require a solder iron.

What would really happen is that a second trader would enter the market, offer to buy the laptop for 110$, hold onto it and then sell it on for 140$. Actual prices vary and with enough competition, will settle to something that gives the trader still a nice profit and enough cash to insure against the risk of such an operation (the trader doesn't know up-front when he can actually onload the goods and how far the price might move meanwhile).

Of course, if you're not desperate on selling right now and or the risk for the trader is too high (i.e. the minimum price you'll sell right now is higher than what the trader is willing to offer you right now), nothing happens.

Concluding, traders do add utility to a market. And as others have already said, with high freq trading it mostly results in massively reduces spreads (and the temporal utility as outlined in the laptop example essentially disappears).

I've studied math. The most recent mathematician I can recall by name (due to a few important theorems) has been doing his great work in the 1930s. Most of the stuff is older. I don't care squat about the gender, but they're likely all male.

Looking at gender ratios in students it's about 50-50 now (ETH Zürich, Switzerland), massively thinning out towards the top (professors are just a few out of 50). It'll take time and untill female mathematicians have an about equal importance in the curriculum students learn, likely a few hundres years. Maths really ages slowly (often because theories get update/extended, but the name sticks).

So being able to name female mathematicians imo doesn't have much relevance to the gender discussion. Luckily society changes faster than math ages ;-)

.2 is way to short. Only works when you're anticipating something and have all your muscles prepped for action. The realistic figure is 1 second for an attentative driver, a bit less if there is some signal ahead to anticipate the situation, way more if distracted by something (e.g. looking in the mirror for a lane change).

And to further your point even more, machines are much better at keeping the required distance for safely stopping. Stressed-out/aggressive humans tend to tail-gate ...

It doesn't because it isn't ;-)

In real sword fights the defenders jobs is to deflect the attackers stroke (more or less). If you'd just try to stop it (physically reversing the attacker's impulse) that would either not work at all (because you don't have strong enough muscles) and the sword would still hit you. Or equally bad, the sword or your bones break due to mechanical overload.

Now according to the description the robot simply pulls back if it hits resistance, which results in the fake looking moves. Deflecting a stroke probably wouldn't work because of the robot's mechanical structure is much more rigid than a human's.

Slow-motion sword combat works/looks much better if the fighters are aware of how it actually works when not simulating the moves.

Amend: The "physically reversing the impulse" is a bit hand-wavy. You just have to put an equal momentum into your own sword directly opposing the momentum of you opponent's sword. Now if your attacker goes in for the long haul, he has about a meter of movement to put the momentum into his sword, whereas the defender usually has much less. This therefore requires much more force resulting in the above consequences.

In all the discussion here, I think yours is the absolutely best analogy. Perfectly illustrates the cost of brute-forcing versus the accused just revealing the crucial little information. Even informed guessing of the password is covered (the accused was seen lately in that corner of the Mojave, maybe the box is there?).

Add to that that at least my muscle memory is especially flaky when I try hard to remember what I'm actually supposed to type and/or I'm otherwise under stress/nervous. Usually just not thinking about the password for 5 minutes works, potentially facing 10 years in prison is certainly not gonna help.

Actually this is about one of the first things you learn in in a probability theory course, and the probability that bogosort completes in finite time is 1.

Now of course, there's infinitely many conceivable scenarios where bogosort never completes, but it doesn't matter. The theoretical foundation (Lebesgue measure theory) to make this mathematically rigid is a bit complex. An example to illustrate:

Assume you have're looking at a 2-dimensional space (over the real numbers) and you want to measure the area of subsets of it. E.g. the area of a square defined as:

{ (x,y) \in \R | 0 <= x <= 1 and 0 <= y <=1 }

Now the area of that is 1. Then carve out the y-axis like this:

{ (x,y) \in \R | 0 < x <= 1 and 0 <= y <=1 }

It's obviously a smaller set than the square above, but the set that's missing doesn't have any area (it's a line with no width). So it's sane to assume that the area of the new subset is still 1.

[btw: Lebesgue measure theory throws in a few more simple assumption and then derives a very nice theory for computing areas, and in extension integration of functions.]

Now probabilities are the same: Instead of points in the plane you have different runs of bogosort and the measure of the "area" for all events is defined to be 1. But you still can carve out complete "lines" (i.e. sets with even infinte many different runs of bogosort) that don't have any influence on the value of your total "area", i.e. probability.

To conclude, your in /pratice/ actually holds up in theory, too ;-)

Edit: Lebesgue measure is actually only the application onto real spaces, the fundamental thing that also applies to probabilities is just called measure theory. Mixed that up a bit.

It's the "by default" that's important. You can still use lvm to resize your partitions. But resizing volumes within the btrfs partition will be done by the btrfs tools.

Assuming your sitting in front of a terminal that has the subscription. I'm still loathing my university's vpn solution for being soooo dog-slow, but it was the only way to read intersting papers from home or gather all the references for a bit of research. Now that I'm out of my studies I'm totally deprived of that pleasure. Yeah, you could go to the library. Hell will freeze over when I do that just to scroll over an interesting paper on a slow day.

And the most infuriating thing: I'm already paying for most of the public research with my taxes.

It's not that they're blissfully unaware. It's being thaught in school and almost all official writing is done in the so called 'written German'. But it's simply not the language you speak (safe for a reason to the contrary, like not everybody understanding it). Even in written (private) communication it's used quite a lot, like in mails, sms, ...

Oh, and at least for Swiss German: It is kinda a different language (but extremely related to the written German): It's not just an accent with some funny words, but has a slightly different grammar, too. Most glarious is the lack of most of the verb tenses in Swiss German. So pupils have to learn quite some stuff to be really fluent in written German.

And even just within Switzerland there are dialects I don't understand (as in no clue what they're talking about). People speaking these usually switch to a more conformistic pronounciation when talking to people from other areas and don't use some of the more obscure words.

And for the reasons this all exists (at least for Switzerland): It's cultivated and all kinda part of your local/national identity. Politicians who speak a "too good" written German are deemed suspicious, almost all of the local culture (theater, local movies, even most of the Swiss tv produciton ...) is in Swiss German.

[Native Swiss German speaker, here.]

Iirc the way to reboot an x86 machine is to triple-fault, i.e. execute an interrupt in an interrupt in an interrupt. Could be done by e.g. marking the pagefault handler's stack space as "not available" in the pagetables.

Now if the virtual cpu does not implement that reboot behaviour, the likely result is just an endless recursion of fault handlers. So the script runs an endless loop, hanging Firefox until it notices this and stops it.