acapybara

Its position is only a "gentle suggestion" to the software to move volume up or down.

At times, especially when starting the vehicle, there is major latency in the software processing the knob movement..

Also, if the knob is moved too fast, the sw gets the wrong reading.

This results in volume being way too high for serveral seconds as well as many other frustrating, dangerous situations.

UX in cars made in the 60s were better than this.

I don't think slapping on fake physical knobs onto laggy buggy software is a solution at all.

    kill $(lsof -t -i :PORT_NUMBER)

The only real security you have is your own assets and financial discipline.

Gaming, for example.

I wonder how hard it would be to boot directly to a wine/proton + graphics & I/O drivers + game environment.

Essentially turn a computer into a console.

This will probably be (or already has been) solved by large transformer models or their successor architectures.

What was missing was common sense reasoning about what they see. We now have that.

I suspect if we can fine tune and optimize this 65B model, we can achieve some truly remarkable results.

Makes it seem like GPT4-level capability could be within reach on current workstation-level hardware, with enough optimization in data, model training, software, and hw specific optimizations.

(Intuition, not hard theory --though I'd argue intuition should not be thrown out wholesale)

But rn it's totally doable to run a 65B or 100B model on CPU with a reasonable workstation.

Does Moore keep us from wiring more memory onto a GPU? Or making a GPU with expandable memory (slots?)

I don't mean any offense toward you.

Just having an incredibly hard time making any sense of what you wrote.

I'd like to know, too... for the record.

Completely disconnect battery when not in use.

Bug Hunters

Extremely valuable service. I bet there'd be a lot of demand.

Give Fedora or Ubuntu a try.

Alpine is not meant to be a no-tinkering desktop distro.

These aren't supposed to be on hn.

Linux is a kernel.

People often refer to the whole system as Linux, but what they really mean is GNU/Linux.

  What's new in this release:
    - Bundled vkd3d upgraded to version 1.7.
    - Better error reporting in the IDL compiler.
    - Support for shared Wow64 Classes registry key.
    - More cleanups in IME support.
    - Support for configuring a WinRT dark theme.
    - Various bug fixes.

Space itself is expanding.

My experience in the software industry (20 years now) showed me that the best ones were the ones who got into it out of genuine interest. They tended to write software as a hobby.

There was no shortage of CS grads who couldn't be nearly as productive.

The self-taught ones, or the ones with genuine interest who also completed a degree program were the best.

I wouldn't discriminate against "boot camp coders" or people who learn things from YouTube.

There's a lot of people who live in a different world where an expensive college/university education is not an option.

I've never had a single issue like this on any of my Thinkpads running Linux.

They're built solid and take a lot of abuse.

You're exactly right --and there are some ways to solve the problem while remaining decentralized.

The ideas you bring up are, essentially: credit, insurance, risk, reputation.

Tracking reputation on-chain is workable, and already exists. For instance, some airdrops have been done based on on-chain activity and reputation. Decentralized founders wanted to reward those with "good on-chain behavior."

The way I imagine this would work for a decentralized Uber:

  - Pay for fares on-chain (ideally, a 2nd or 3rd layer, e.g. a ZK rollup)
  - Drivers rate users on-chain, using the payment address
  - Possibly use other on-chain information to form a "credit/reputation profile"

To protect privacy, we'd need to take extra care to shield user info (using e.g. ZK proofs), or just make everything completely transparent. It's also possible to use privacy for the payments/assets system, and make the reputation system transparent.

I do not think we'd want to be storing ride data, etc. on-chain. I'd look into something like OrbitDB, or some other decentralized system that's meant to be a database.