Alex @ stsquad @lemmy.ml

FLOSS virtualization hacker, occasional brewer

---

Read more

Posts

10

Comments

348

Joined

2 yr. ago

Time to audit all their contributions although it looks like they mostly contribute to xz. I guess we'll have to wait for comments from the rest of the team or if the whole org needs to be considered comprimised.

NI is just another tax that goes into the total pot, albeit one that is not progressive and adds to the cost of employment. I'd be happy with it being scrapped and it all going on income tax, perhaps with a scaled employer contribution component. How about the employer contributes a scaled percentage for all employees over the median income for the company?

Microsoft has been working with a number of open source projects for some time now. It shouldn't be that surprising anymore.

European systems have quite a bit of private provision but they are still generally single payer and heavily regulated. Private involvement in healthcare doesn't automatically involve what they created in the USA.

I think narrowing it down to one tax type isn't overly helpful. Ultimately it comes down to spending and policy. We underspend and we are more reactive: https://data.oecd.org/healthres/health-spending.htm

Systems that are insurance based (ignoring the mess that is the usa) at least have an incentive to catch things early because they are cheaper to deal with before they become chronic. With delays in primary care and waiting lists we end up getting much less bang for our buck as conditions develop before getting treatment.

We have a lower tax burden than most of Europe, or at least the ones with decent healthcare. https://data.oecd.org/tax/tax-revenue.htm

The declarative approach also allows for better composability - user tweaks can just be the relevant lines on top of the packaged default config.

You can end up with a lot of boiler plate code and with duplication you run the risk that one unit tweaks the boiler plate in a way that behaves differently. This isn't insurmountable and a lot of rc scripts source a library of common functions shared between units. However from the point of view of the executor each unit is it's own whole ball of shell script code.

Yes training is the most expensive but it's still an additional trillion or so floating point operations per generated token of output. That's not nothing computationally.

While shell based RC systems do offer flexibility they also have downsides including copy and paste leading to subtly different behaviour across units. Dependency resolution was also a bit of a hack on top of scripts to deal with concepts like run levels.

The declarative approach of a proper configuration is a better and more scalable solution.

It's about time. I know there was a desire to avoid over regulating the burgeoning internet economy but we reached the era of monopolies a while ago now.

So is the theming here for the window decorations or the text colour scheme?

How much theming does a terminal need? Personally my required features were a server and good font support. Currently I use the foot terminal: https://codeberg.org/dnkl/foot

They have been working on VirtIO vulkan support as well as native context support for their cards.

It's entirely configurable but I think by default sudo will "cache" your authentication for a period of time so multiple commands in the same session only need the password entered once. You can even configure sudo to not need a password for certain commands (although obviously you need to be careful you're not opening a hole in your security).

The ISA may be open but I'm pretty sure the microarchitecture will be totally proprietary. Even with a kick ass microarchitecture they may still struggle if they can't use the latest process nodes to actually manufacture the chips.

Having said that I suspect the main challenge RISCV is going to face is the software ecosystem. That stuff can take a decade to build and requires a degrees of cooperation between all the companies building chips.

I was sadly stymied by the fact the rocm driver install is very much x86 only.

That's just an a architectural description, any non toy implementation is still propriety. That's without solving the layout and tapeout for whatever highly propriety process node you plan to build on.

That's cool. I've just recently gotten hold of an interesting Ampere system and it's got an AMD card in it. I must give it a spin.

So I may be biased but what is vmwares USP? From my limited experience it was a slightly more polished GUI for creating VMs and the ability to run on older pre-virt hardware. Is the experience still objectively better than the alternatives?