Hacker Newsnew | past | comments | ask | show | jobs | submit | RodgerTheGreat's commentslogin

"you don't have -wTokenHashCollision enabled! it's your own foolish ignorance that triggered UB; the spec is perfectly clear!"

Hey stop it with the ad hominems!

Is "energy capsules" a euphemism for amphetamines?

I was taught that it was more a memory device for recognizing major depressive disorder as a state of sadness and low energy. The treatment, I presume was still SSRIs first line.

There are a variety of open-source 3d-printable adapters to mount glasses within full-face respirators. I use a version of this design with my 3M 6000-series and an old pair of lenses:

https://www.thingiverse.com/thing:4672869


I did a double-take at

    > Executes one line of script per frame (~60 lines/sec).
Makes the "runs at 60FPS" aspect of the engine feel a lot less relevant. At this speed, anything more complex than Pong would be a struggle. Even a CHIP-8 interpreter is usually expected handle a dozen or so comparably expressive instructions per frame.

Which is why I love this. Extreme constraints. Takes a lot of creativity to make something interesting, without feeling overwhelmed with possibility. I'm considering making tiny arthouse game projects with this.

Don’t worry, you can’t have that many lines anyway…

> Up to 128 script lines per program


I agree. It seems like interpreting one instruction per frame is the developer's way to guarantee real-time performance. I don't want to discourage the developer from experimenting with this design. What I think they should do is determine the most instructions they can interpret each frame.

I like the idea of on-device programming like this. While I haven't used it, I know there is a DSiWare application Petit Computer that lets you implement more complex (sprite-based) games in a Basic dialect: https://en.wikipedia.org/wiki/Petit_Computer. As DSiWare, it has an official video trailer: https://www.youtube.com/watch?v=4AYlEo3rJHs.


،sh12

I stand by a policy that if a feature in one of my projects can only be implemented in Chrome, it's better not to add the feature at all; the same is true for features which would be exclusive to Firefox. Giving users of a specific browser a superior experience encourages a dangerous browser monoculture.


Not writing the feature makes sense, but pushing Firefox and Safari to add support would be pro-social if you're up for it. The most common reason for browsers not to add support is something like "this can be done in other ways, and it has maintainability/security/bloat downsides". Running into a feature you can't build is evidence on the "this can be done in other ways" question (but of course the other downsides could still be big enough that it's not worth doing).


I say the following as a firefox+ubo user:

There are many useful things that can only be implemented for Chromium: things like the filesystem API mentioned in this post, the USB devices API used to implement various microcontroller flashing tools, etc. Users can have multiple browsers installed, and I often use Chromium as essentially a sandboxed program runtime.


SOME users can have multiple browsers installed. Some can absolutely not. In fact, 1.6 billion users can only have one installed and it's not Chrome or Chromium based.


Assuming you're talking about iOS: and their OS won't let them install your app to manage files or flash microcontrollers anyway. It's not your problem when they choose an actively hostile platform.


Firefox is only a few percent market share. You are hiring your users for not improving their user experience because it's not compatible with one of the a web browsers on a few percent of people's computers.

Chrome add these features because they are responding to the demands of web developers. It's not web developers fault if firefox can't or refuses to provide apis that are being asked for.

Mozilla could ask Claude to implement the filesystem api today and ship it to everyone tomorrow if they wanted to. They are holding their own browser back, don't let them also hold your website back. In regards to browser monoculture there are many browsers built on top of the open source Blink that are not controlled by Google such as Edge, Brave, and Opera just to name a few of the many.


Yep. J has a small userbase, but it isn't fragmented into dialects like K or even APL, J uses ASCII characters instead of requiring a custom font/keyboard layout, J is FOSS, J has extensive learning materials, and J is reasonably batteries-included and suitable for making practical nontrivial programs.

I like K better than J aesthetically, but it's harder to recommend to beginners due to the fragmentation of the ecosystem.


If one is golfing, tacit would be tidier:

    5(|+\)\1,1


No code architecture will enforce privacy or guarantee security.

Some code architectures make privacy and security structurally impossible from the beginning.

As technologists, we should hold ourselves responsible for ensuring the game isn't automatically lost before the software decisions even leave our hands.


To be more precise: America could easily afford healthcare, but American elites regularly accept pathetically tiny bribes to pretend that universal healthcare is impossible. They also accept pathetically tiny bribes to allow companies like OpenAI to do whatever they please without meaningful legal consequence, so OpenAI is able to keep getting away with shipping products that cannot work as advertised and will kill people.


1. The people working for these companies are already demonstrably ethically flexible enough to pirate any publicly accessible training data they can get their hands on, including but not limited to ignoring the license information in every repo on GitHub. I'm not impressed with any of these clowns and I wouldn't trust them to take care of a potted cactus.

2. The risk of using "illegal" training data is irrelevant, because no GenAI vendors have been meaningfully punished for violating copyright yet, and in the current political climate they don't expect to be anytime soon. Even so,

3. Presuming they get caught redhanded using personal data without permission- which, given the nature of LLMs would be extremely challenging for any individual customer to prove definitively- they may lose customers, and customers may try to sue, but you can expect those lawsuits to take years to work their way through the courts; long after these companies IPO, employees get their bag, and it all becomes someone else's problem.

4. The idea of using carefully curated datasets is popular rhetoric, but absolutely does not reflect how the biggest GenAI vendors do business. See (1).

AI labs are extremely shortsighted, sloppy, and demonstrably do not care a single iota about the long term when there's money to be made in the short term. Employees have gigantic financial incentives to ignore internal malfeasance or simple ineptitude. The end result is, if anything, far worse than stupidity.


There is an important difference between openly training on scraped web data and license-ignored data from GitHub and training on data from your paying customers that you promised you wouldn't train on.

Anthropic had to pay $1.5bn after being caught downloading pirated ebooks.


So Anthropic had to pay less than 1% of their valuation despite approximately their entire business being dependent on this and similar piracy. I somehow doubt their takeaway from that is "let's avoid doing that again".


Two things:

First: Valuations are based on expected future profits.

For a lot of companies, 1% of valuation is ~20% of annual profit (P/E ratio 5); for fast growing companies, or companies where the market is anticipating growth, it can be a lot higher. Weird outlier example here, but consider that if Tesla was fined 1% of its valuation (1% of 1.5 trillion = 15 billion), that would be most of the last four quarter's profit on https://www.macrotrends.net/stocks/charts/TSLA/tesla/gross-p...

Second: Part of the Anthropic case was that many of the books they trained on were ones they'd purchased and destructively scanned, not just pirated. The courts found this use was fine, and Anthropic had already done this before being ordered to: https://storage.courtlistener.com/recap/gov.uscourts.cand.43...


Their main takeaway was that they should legally buy paper books, chop the spines off and scan those for training instead.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: