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

Standing by; three times is enemy action

This is third time. Two months ago a railway was sabotaged on the other side of the EU: https://www.bbc.com/news/articles/c4gknv8nxlzo

Another train derailed due to the storm between Blanes and Macanet with no one injured.

Is this better or worse than a world in which "news" becomes about "tweets?"

> PCI is very delay-tolerant

That fascinates me. Intel deserves a lot of credit for PCI. They built in future proofing for use cases that wouldn't emerge for years, when their bread and butter was PC processors and peripheral PC chips, and they could have done far less. The platform independence and general openness (PCI-SIG) are also notable for something that came from 1990 Intel.


That has a name: ExpEther[1], and likely more than one. pciem does mean you could do this with software.

[1] https://www.expether.org/products.html


> Really needs an agent-oriented “getting started” guide to put in the context, and evals vs. the same task done with Python, Rust etc.

It has several such documents, including a ~1400 line MEMORY.md file referencing several other such files, a language specification, a collection of ~100 documents containing just about every thought Jordan has ever had about the entire language and the evolution of its implementation, and a collection of examples that includes an SDL2 based OpenGL program.

Obviously, jkh clearly understands the need to bootstrap LLMs on his ~5 month old, self-hosted solo programming language.


a.k.a. jkh. That's a blast from the past. Back in the early FreeBSD days, Jordan was fielding mailing list traffic and holding the project together as people peppered the lists with questions, trying to get their systems running with their sundry bits of hardware. I wondered when he slept.

Apparently he did as well[1]: "The start of the 2.0 ports collection. No sup repository yet, but I'll make one when I wake up again.. :)" Submitted by: jkh Aug 21, 1994

[1] https://github.com/freebsd/freebsd-ports/commit/7ca702f09f29...

Interesting commit starting Ports 2.0. Three version of bash, four versions of Emacs, plus jove.


> Why are they comfortable saying this?

They receive recognition for the results. Phone data was used in a large fraction of the cases against rioters in the 2021 capital attack. The Powers That Be were grateful that law enforcement were able to use phone data to either initially identify attackers or corroborate other evidence, and ultimately put people in prison. The justice system makes cases with this every day, and the victims of criminals are thankful for these results.


Tools like this are substantially different than time/location Bound geofences with warrants served to providers like were used in the Jan 6 investigations. And even those are under SCOTUS scrutiny for 4th amendment concerns.

Results compel expectations, and every "success" unlocks more latitude. A rational person cannot admire headlines that trumpet the wonderful achievements of digital dragnets in one case, and then suffer "concern" when more aggressive techniques are employed elsewhere: there are powerful incentives involved, as any thinking person should know. J6 was a big unlock for state surveillance; the results were met with gushing praise and no friction was incurred. Now, new bounds are being pushed and the tools proliferate, as the fine distinctions you cling to are blithely forgone.

J6 was a completely standard use case to confirm someone’s location in the Capitol with the location data from providers. It wasn’t some novel or breakthrough use, and not everything in life is a slippery slope so it’s completely rational to approve of a technology to convict those involved in a crime and decry more advanced and less legal means purely for surveillance of people who haven’t committed any crimes.

I've heard a lot more recognition for Apple refusing to comply with unlocking iPhones over the years than any of these other cases.

This might just be the bias of the groups you are in (myself included).

I think there's also the bias in that it's normal to comply in the first place, and there'd be no fanfare about it.

I don't like being devil's advocate on this because I am strongly against the invasion of privacy at that point in the investigation, but without that data, they'd just take a bit longer to have identified the members of the insurrection. There's varying degrees of data you can glean from cellular networks as well, right down to "it was definitely this person, the phone logs show a FaceID unlock at X time" and that action can be inferred by network logs, all information that carriers have retained for over two decades.

What it does become is a data point in an evidential submission that can strengthen a case that could otherwise be argued back as a bit flaky. It's similar to DNA evidence in that it's not actually 100% reliable nor is the data handled forensically at every stage of collection, but it's treated as if it is.

I think it's weighted too heavily in evidence and should not be used as a fine-toothed comb to sweep for "evidence" when it can be so easily tainted or faked. At the same time, I'd love to see the current members of the pushback against ICE using this data fallacy against future prosecutions. "Yeah, I was at home, look" and actually it's just a replay of a touch or face ID login running from a packaged emulator, or whatever signature activities meet the evidential requirement.


>they'd just take a bit longer to have identified the members of the insurrection

They'd have had to enjoin more parties, probably to include state agencies. Any party can push back, stall or blow the whistle if they feel something wrong and risky to them is happening. Which is exactly the opposite of what the feds want. They want to act unilaterally, on anything and everything.


Without getting too political, the US is observably turning agencies over to their own people for exactly reasons like this, the feared "deep state".

I suspect we're about to see all kinds of abuses of information in the US.


appeal to emotion

> Preact is only 4.7 kB

Is there some outlier place where people using virtual DOM frameworks don't also include 100-200kb of "ecosystem" in addition to the framework?

I suppose anything is possible, but I've never actually seen it. I have seen jQuery only sites. You get a lot for ~27kB.


I use Preact for a very lean build for a front-end that lives in a small embedded MCU flash ROM. Gziped the whole front-end is about 25KB, including SVG images baked-in to the preact gzip file. I'm very careful about the libraries I include and their impact on the overall payload size.

I had started with a simple front-end that was using jQuery to quickly prototype the device controls, but quickly exceeded my goal of keeping the front-end at under 40KB total gzipped. The problem is needing more than just jQuery, we also needed jQueryUI to help with the front-end, or build out similar complex components ourselves. And as soon as the jQuery code became non-trivial, it was clear that Preact made much more sense to use. Our payload is quite a bit smaller yhan the jQuery prototype was.


I do that when I need to make a simple SPA. Plain Vue plus a few tiny add-ons of my own.

Look at Deno + Fresh which is based on preact. You can do a lot with preact only

Exactly. Contrast or, more precisely, the dynamic range we desire, is ruined by dimming displays enough not to cause pain and fatigue.

It's a dumb solution, and we may all safely ignore it, knowing it won't occur. "Dark mode" haters will just have to cope as dark becomes the default.


> I’ve never met a person saying they hate books and wish they were white on black.

I've never seen a book actually radiate its own light. Perhaps if there had been 600+ sq. inch self illuminating books, we might have invented dark mode long ago.

During the early days of CRTs, dark mode was the norm. VT50/100/220, 3270 etc. were almost always dark with illuminated characters, and even when not, they were only ~12-14" diagonal, and there was only one. Most PC/DOS machines were the same. The moment raster displays appeared, everything went "light mode," but they still weren't very large. Then, displays got huge and multiplied, easily able to overwhelm human eyes with excessive power.

The ~30-year detour into Apple/Microsoft's paper-mimicry is ending due to basic ergonomics. No need for your tut-tutting.


Books reflect ambient light. Monitor brightness should be set to a similar light level. You can hold a book next to the display and adjust accordingly.

That's an unreasonable ask. I'm not gonna fiddle with the brightness of my monitor throughout the day, thanks

If you control your ambient lighting or use automatic adjustment, you don’t have to.

I can count on one hand the number of monitors I've seen with auto brightness. The number of monitors with acceptable and non distracting auto brightness is zero.

I mean, if you have a modern digital display you might be able to change the brightness through the DDC/CI protocol and a simple app or extension, available in every much every OS. With a keyboard shortcut or two clicks you change it. Fiddle with monitor settings is painful, but that protocol is a godsend. Even one of my cheapest 13 years old monitor supports it.

> Books reflect ambient light.

Thanks! I always wondered how books worked.


> I've never seen a book actually radiate its own light.

Plenty of ebooks with built-in illumination, you know.

> During the early days of CRTs, dark mode was the norm.

Yes, because they were physically unable to do anything else! A pixel could be either 100% off (black) or 100% on - and if you were unlucky the "on" was something obnoxious like bright green. The fact that basically everyone switched to light mode once it became feasible should be a hint that it wasn't just a designer fad.

> easily able to overwhelm human eyes with excessive power

The sun is orders of magnitudes brighter - even when it isn't a blue-sky day. Human eyes evolved to deal with that without any issues (that's why your pupils can vary in size), so a desktop monitor shouldn't be a problem.

The problem is contrast. If you sit in a dark room with your monitor turned to 100% brightness and you're using a light theme of course your eyes are going to hurt. It's the same with those obnoxiously bright headlights we're seeing on cars these days! Sure, you could use dark mode, but the problem can also be solved by making sure the room is properly lit, or turning down the monitor's brightness. No need to pretend dark mode is a one-size-fits-all must-have solution for "ergonomics".

The same applies the other way as well, by the way: in my experience dark mode becomes completely unreadable in a brightly-lit environment - especially on glossy screens. You're constantly dealing with annoying reflections hiding your content.

Personally I've grown fond of the way MacOS and Android handle it: automatically switch to light mode while the sun is up, use dark mode during the night. It's not perfect in every situation, but 99% of the time it gets me what I want.


> Plenty of ebooks with built-in illumination, you know.

I do! And here's dark mode feature for one of them[1].

[1] https://www.amazon.com/gp/help/customer/display.html?nodeId=...


> Plenty of ebooks with built-in illumination, you know.

If your screen has built-in illumination then you might want to use a white-on-black theme. Mostly everything supports it, txt readers, epub readers, pdf readers (pdf.js not yet, but other pdf readers).


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

Search: