jcelerier

They did not change the laws.

yes they did?

in Québec: https://www.ctvnews.ca/montreal/article/uber-is-officially-a...

in France: loi Thévenoud and Grandguillaume (which were the follow up to negociations between the french gov' and uber), etc.

other countries are the same around the same period, e.g. https://legislation.nsw.gov.au/view/html/inforce/current/act... etc etc

it was a crime to run your own unregistered taxi service in many places until uber came and the laws changed to adapt

Alternatively, perhaps we'll see models fine-tuned or steer-able towards accuracy that customers can themselves use to get a more honest view on what the product would look like in person.

we live in a world where the norm is to use filters on pictures of your own face to lie about how you look, imagine thinking than people actually care about truthness

Isn't it borderline illegal for publicly traded companies to not try to maximize profit? "interest of the company" in theory but in practice

Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".

... that's a very normal constraint in many fields of SWE?

Not even, this was deemed too insecure. So now we have to have one protocol per-use case instead of something that allows to handle easily all the use cases we already know exist - the most stupid thing possible

it's the clash between reality and the intent (whether a location or practical set constraints), the individual skill of everyone involved, costume and prop department

That's not art, that's the limitations that everyone working in this industry have been working night and day to overcome for hundreds of years

The protocol for this has recently been accepted, now it has to be implemented by every compositor

The required high degree of connectivity might be attained with the help of microminiature radio transmitters and receivers.

I mean pretty much everything has a wifi chip these days

I've seen developers pushing code repeatedly to car engine firmware with for-loops that weren't even valid C syntax, have yet to see a modern LLM do this kind of mistake

computers and Internet shouldn't exist and life would be better

I don't think that's remotely controversial

there's at least one customer in need for a product

just because whales exist does not mean feeding them is a goal to aim for as a society. 99.9% of technology could disappear tomorrow and life would become better.

What's your opinion on software like https://www.autohotkey.com/ then?

But a lot of people are still running macOS < 10.15

In throughput but not in latency, and especially not in variability

It's crazy to me to think that I was hoping to move my home network to 10GbE in the next few years, around 2006-2007... Twenty years after most home networking is still at the 2005 level of a 30€Netgear GS108

Pretty sure esp32 just rebooted automatically when unhandled exception is thrown for instance

If you add exceptions to a library that didn’t previously use them then I almost definitely have to update my code.

No, that's the whole point. You let them bubble up to the top of the event loop and you report the error to the user. As a user, anything else leads to shitty software where the programmer tries to outsmart the world around them (and fails, obviously, leading to worse end-user experience than just admitting that you don't and can't have control over everything)

More nails does not create more house.

sure, but less nails definitely prevents you from having more house

If you crash from an unhandled exception, you don't.

.. you absolutely get a stack trace from unhandled exception in c++, that starts where the exception is thrown? At least with clang and GCC, maybe MSVC isn't able to.

foo.cpp:

    #include <stdexcept    
    void bar() { throw std::runtime_error("boo"); }
    void foo() { bar(); }
    int main() { foo(); }

    $ g++ foo.cpp -std=c++23 -g
    $ ./a.out
    terminate called after throwing an instance of 'std::runtime_error'
      what():  boo

    $ coredumpctl gdb
    ...
    #7  0x00005555555551bb in bar () at foo.cpp:3
    #8  0x00005555555551da in foo () at foo.cpp:4
    #9  0x00005555555551e6 in main () at foo.cpp:5

It's crazy for me to think that people cannot see how wrong it is from the normal speed video. For me it's obvious and infuriating, it physically feels like it's punching my retina

If you can deliver the same thing in fewer correct lines of code

it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.

Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?

Apparently roughly ~150k math PhDs live on earth right now, assuming they all know Lean that's between 0.001% and 0.002% of earth population so quite closer to no one than one

Allowing closed-source to exist is always the less moral choice for many reasons (one example being ecological sustainability)

How fast do you want your slideshow to be?

we're in 2026, 240hz screens are becoming common. Nothing in the end-user experience should take more than 3-4ms. My personal goal when developing is keeping things at at least 60FPS and ideally 120 when building the whole stack with ASAN / UBSAN / stdlib's debug modes.

For instance when looking at this the first thing I thought was to try to make an installation which permanently recurses the codec's application on itself at each frame, to give the impression of a constantly moving landscape. Impossible on a smaller machine if computing a single frame takes 150ms.

would be great to have the weights somewhere

or maybe erlang / elixir do not have 1/1000th of the libraries and features available to C++ thus it's more efficient to port what can be ported? would you rather have the whole of C++ ported to erlang?

next intel cpus will have AVX 10.2 & APX

export to large files that represent numbers in textual format for instance ? this can be the difference between "waiting 10 seconds when hitting ctrl-s" and "the software saving automatically on each change because it's unnoticeable"

it's OK to not be the most efficient all the time

is it ? it's a non-negligible reason for the absolutely unsufferable technological world we are currently living in