jatone

fundementally this is due to bitcoin's lack of adoption as an actual currency. the larger the user pool the less it would fluctuate.

redhat contributes to firefox, and firefox contributes a bunch downstream in the form of bug fixes and reporting due to their error telemetry.

its almost like they have different departments.....

I'm literally paying for the VPN product they have because its the only subscription service they really offer. I never use it because the linux integration is terrible. lol

depends on how frequently you need a car. I drive maybe 3 times a year. that's ~2k in gas/rent fees. that's less than insurance assuming each rental is for a week. never mind the cost of actually buying the car.

in practice I spend maybe 1k every year for cars. primarily for vacation. which owning a car wouldn't absolve me from spending.

100% on restructuring to improve tooling. discoverability is the big thing we lack. from would be a little more verbose than necessary but otherwise yes!

wow. just.... wow.

I didn't say it was unreasonable to expect x11 to work. I said it was unreasonable to expect a modern API to jump through hoops to work on x11.

x11 works fine as is, and will continue to do so through xwayland. but don't expect new apis to give a rats ass about x11.

the last release was afaik I know just to get the majority of patches contributed out that had stagnated and to finally split xwayland out of the xserver release.

https://www.phoronix.com/scan.php?page=news_item&px=XWayland... https://www.phoronix.com/scan.php?page=news_item&px=XWayland...

its dead, the maintainers have said its dead, all major distros have either moved or will be moving in the coming year. x11 as an api will limp along due to xwayland but that's about it.

no amount of assertions will change that unless individuals/organizations step up to actual maintain it.

as for rest of your statement ./shrug I've already been very clear on the fact they were already using a gnome only api incorrectly. the generic desktop portal api not being strictly ready in 2020 due to pipewire doesn't change the fact they had a perfectly reasonable api to use inside gnome and they decided not to and were burned.

1. no its not, no security fixes or new features are being developed, its entirely on life support: the changes are to just keep it limping along while distros finish transitions to wayland. https://lists.freedesktop.org/archives/xorg/2022-January/060...

2. the article is about them abusing a gnome only API when alternatives existed that would have worked better. WLR had its first commits for its desktop portal api in 2018, gnome has had some form of the desktop portal api for 8 years now.

if you're going to use a DE only API at least use the right fucking one.

x11 is no longer maintained. you're thinking of xwayland, which is the only thing getting releases these days. but that is built on wayland.

gnome shell has had some version of the screencast API for 8 years now. pipewire is irrelevant to the discussion.

https://gitlab.gnome.org/GNOME/gnome-shell/-/blame/main/data...

the first commit for the desktop portal (which is the end result of the gnome api above) for wlr was in 2018.

https://github.com/emersion/xdg-desktop-portal-wlr/commit/4e...

2 years before the 2020 date in the article. so in short: in 2020 zoom abused a gnome only api to implement desktop sharing, when a proper gnome only desktop sharing api already existed for ~8 years. which was the precursor to the current desktop portal stuff and you're trying to blame wayland for the problem.

flat out incorrect in this case. this has nothing to do with a deprecated API. they just decided to abuse one API when there was an API available for their use case available.

x11 is no long maintained expecting an modern API to support it is foolish.

its entirely zoom's fault. the apis they should be using have been well known and in use for years before they used the improper APIs.

chrome's (and by extension every electron app) issues stem from the fact it had not updated to use the screencasting APIs. afaik they've been updated.

abusing APIs isn't the right way to go here. and zoom is entirely at fault for it. they should have used the correct (and known) apis and worked with upstreams to get the support in place. then they could have properly pointed to upstream and said 'it won't work until these issues are fixed' and provided resources to fix them.

as a result now they are in a shit position of having a completely broken app when the APIs in question do work. I know because I've built a screencasting program on top of them to cast my desktop to chromecast.

yeah I didn't really believe it, just didn't feel like doing the effort of researching it because in reality its never come up in practice for me. which hinted at it not being a real problem anymore.

if i had to guess COUNT(*) may load everything per row datawise vs using a index. but I'd have to run tests to confirm =)

that's because the majority of economic activity are near ports where train wouldn't be as useful. as a result the bulk of goods transported by train are to the lower populated areas where again the last mile is done by truck.

doesn't make trains not vital.

regions have generations. its the same concept just partitioned to make the working sets smaller.

there isn't anything fundamentally wrong with golangs GC. attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant.

the languages have fundamentally different approaches to memory allocations. and the reasons behind the JVM implementations simply do not exist in golang.

the new pacer is in the works to attempt addressing many of the edge cases. https://github.com/golang/proposal/blob/master/design/44167-...

you seem to lack fundamental understanding of what the actual issues in the golang runtime are with relation to its GC.

fundamentally they did, they implemented a generational GC.

The optimizations the JVM does in the newer ones are well understood optimizations but don't address the root issues with implementing generational GC in golang.

the issues was with the write barriers and requirements around moving data which can't be avoided in generational GC implementations because you have to move data and update pointers.

most of the benefits of generational GC doesn't exist in golang because of escape analysis allocating data on the stack.

the metrics have said otherwise. the golang team has implemented more sophisticated GC algorithms similar to the JVM's and the performance differences where negligible and had significant downsides.

uber was able to solve there issue so the GC in golang seems perfectly fine.

oh my a company that runs on over 70k CPUs has atypical problems. surprise surprise. oh and look, they were able to resolve it with a few lines of code. the horror.

seems like they were able to tune it just fine given they wrote a library.

it all depends on what particular detail wasn't able to be predicted. in this case the need for boosters.

we knew by late june boosters would be needed. so all messaging after june should have been consistent. it wasnt.

what wasn't predictable was when precisely we needed to issue boosters and to whom. because we simply didn't have the data on that until around september. However since september it was very predictable that we needed them for the holiday season. I got mine in early november because it was fucking obvious. omicron wasn't 100% assured but it was in the news and most sound bites were 'more contagious'.

its entirely possible to be consistent in the face on unpredictable events.

1. outright say 'we don't currently have the information needed yet check back later' or 'worst case scenario would be X, we're going to start with those assumptions'

2. repeat step 1 until you have the data or know you never will

3. once data is acquired adjust statements.

this is being consistent and clear. another example of this is masking and viral spread.

1. assume worst case for viral spread (airborne)

2. message masks are necessary until more is known about how the virus spreads.

3. if results come back disproving airborne spread, say so.

instead we got:

1. masks not necessary. virus doesn't seem to be airborne.

2. OOPS VIRUS IS AIRBORNE.

the first case is consistent, assume worst case and then ease restrictions. the 2nd case is completely inconsistent.

incorrect. during unpredictable situations it makes it MORE important to be consistent in communication.

consistent communication could have been: boosters are recommended, we'll open them to relevant age groups in the future.

though honestly they should have opened boosters to everyone in september and called it done. we knew then everything we needed to know. which are:

1. risks of the boosters. 2. average declines in protection.

that which is asserted without evidence is rejected without evidence. you under estimate little people give a shit about money after a certain point.

plenty of people in the 100-200k range take cuts in the 30-40k / year range to move to better work environments. so the idea you'll get doctors who generally make 200k+ would be willing to work in shitty conditions for a prolonged period is pretty bogus.

nurses you might be able to entice them to come back for 20-30k bumps, but its also unlikely.

even if your idea worked, it doesn't increase the supply. it just brings us back to predecline levels.

edit: in fact a clear example of your idea not working: paying people to get the vaccine. did jack shit to actual increase uptake.

its the natural outcome to your argument. there simply is no way to increase the supply of highly trained specialists within even a year timeframe.

'incentives' won't help. there simply isn't enough supply in aggregate. and they are not leaving because of a lack of pay they're leaving due to the stress of dealing with assholes on the daily. cash isn't going to fix that problem.

the only option left in such a scenario is literally mandating they return to work. which doesn't nothing be return you to initial workforce levels it doesn't increase capacity.

we're seeing this right now with the national guard 'mobilization' in some areas. they're literally doing nothing but sitting with patients and other menial tasks that don't require training. they're basically just in the way.

nurses take years of training. where are you going to get them during a global pandemic on immediate notice when literally every area needs additional nursing resources?

nurses and doctors are leaving due to the stress of a long term pandemic. are you asserting we can just force them back into labor? that's fairly dictatorial of you. it still doesn't change that we would only revert to original levels, it would not be a significant increase in supply.

you can't add capacity to a system that requires highly trained specialists on a dime. hospital capacity is very much limited by how much it is used on a day to day basis, regardless of pandemic status.

what you suggest simply will never be an effective strategy.

not a biologist, but my current understanding:

immunologically naive means that your body has no prior exposure to a virus (or its variants). basically it means it has NFC how to deal with it. so it basically has to brute force its way to a defense against the strain.

This is why you saw people with early covid cases having their immune system go haywire and a lot of the treatments for covid focused on dampening the immune system to prevent it from killing the patient.

once you've seen a virus and its variants a few times your body has 'remembers' strategies on how to fight the virus. and launches those strategies against it. sometimes depending on the mutations those strategies are less effective (omicron) and your body has to create new strategies.

B-cells and T-cells are how the body store and deploy these strategies.

golang is absolutely capable of writing databases and audio/video code. the libraries just dont really exist for the audio/video stuff.

but there are DBs written in go.

learn both. golang is vastly more productive than rust for me. better tooling, faster build times, smaller less complex language.

rust is fantastic for building highly performant safe code at the expense of developer productivity. builds times are atrocious and tooling isn't as polished as golang.

both at great languages.