rft

Redlib works. Either self host or use a public instance: https://github.com/redlib-org/redlib#instances

Not sure what their plans are, but the Deck has a wifi 6E radio, so maybe they can use it to connect to the Frame directly. Given modern wifi chips can usually operate both as an AP and a client at the same time, this might just be a software feature they add to SteamOS. Worst case you can stream without a dedicated wireless link via your normal wifi with potentially reduced quality.

If this actually works, this is quite a nice, if a bit niche, combination. I really like the control layout of the Deck and it has more performance than the Frame. If you can put the screen on your head instead of having to look down on it, it might be a bit more comfortable. Sadly it seems the Deck has no IR LEDs so it can get picked up like the Controller by the Frame. Maybe a case/sleeve for the Deck can add those LEDs for full integration.

I have a "Homatics Box R 4K Plus" with CoreELEC/Kodi installed. The UX is then determined by your Kodi skin or apps. I wouldn't exactly recommend that box for ease of installation, but it works. It only needed to boot once into Android, annoyingly requiring an internet connection for setup. Since then it only runs CoreELEC. Works via HDMI CEC via the TV remote, which is still a bit annoying, because they had space for a dozen branded streaming provider buttons, but pause/forward etc. are on a mode switch button that overloads the navigation buttons.

For far too many options, see this massive sheet for Kodi support, including newer formats like Dolby Vision and HDR variants: https://docs.google.com/spreadsheets/d/1Uyuw_1dADsRw7u1LGW6q...

Overall I am pretty happy with Kodi on my Android box. 90% of the content is streamed from a local Jellyfin server, so I can't comment on how well it works with DRM media. It occasionally [1] seems to hang, requiring a power reset. The next time it does, I will hook it up to a smart plug to simplify that as well. If you are into tinkering, CoreELEC is based on Linux and you have some basic tools already installed with more available from the addon repos. I have SSHed into LibreELEC to debug network issues with iperf and on a previous iteration to kick over Kodi with systemctl restart.

[1] gonna say less than once a month, I don't remember when it last happened

I intentionally avoid this, especially if I am not the only one connecting to a server. I see potentially breaking others' expectations for my convenience as a clear downside. Plus there is a level of paranoia there, I might have unintentionally included a credential in some config that gets copied over. That potentially increases the blast radius of a server compromise beyond what is strictly required for that specific server. I might copy over some scripts into a directory not in $PATH, easy enough to add it to my shell session if needed, CTRL+R helps as well.

ssh, scp, tmux, (grml-)zsh, grep, less, file, tar, git

The time saving of a well filled ~/.ssh/config is impressive, especially once you start juggling ProxyJump hops.

Chris just has some fun projects. Sandsifter was pretty well known back then due to finding that VIA x86 opcode, the movfuscator is just an amazing piece of mostly useless engineering and the fun reverse engineering psychological warfare was my first contact with his projects. I guess someone stumbled on one of his projects and others clicked through to his other projects. Many of them are a perfect fit for HN, no wonder they got posted.

I get that argument, but I don't think it is that bad. Open weights that are out of reach for local use are still within reach for groups of people or small to medium companies. Even if you only rent enough cloud GPUs to run the weights for a few hours, you still get to do anything you want with it.

Worst case you can still archive the weights and hope for capable hardware to get affordable. At the same time this archive is the base line for a new frontier lab to start over if required. I see open weights as a pure upside even though I can't run the bigger models in my home lab.

Article is missing a note on the existence of MX records for the domains. Sure, you can easily have a send-only domain without an MX record, but the common case is likely to setup both send and receive capability. It would be interesting to have that number included as domains without MX and DMARC might just not be configured for email at all. Worst case the 45% of domains without DMARC are simply not relevant for email and thus not configured at all. I would find "x% of domains with configured email don't enforce DMARC" more interesting.

Those numbers are wrong for most use cases. Likely the LLM did not take SWA (Sliding Window Attention) of G4 into account. Without SWA those numbers could be correct, I can't load a q8 without SWA on a 24GB card.

I tested this with the at the time newest llama.cpp master on a Linux system with 2 3090 24GB, only one was used for testing. q8 without any KV quant, 256k context, mmproj loaded takes less than 20GB VRAM. This runs at about 1.5k to 2k tok/s pp and 40-50 tok/s gen (slightly lowered power limits & undervolted). q8 with 64k non-quant context and mmproj takes just under 16GB VRAM. Drop down to the q6k model, no mmproj, 64k non-quant context and it fits in 12GB VRAM. All the way down to q4km and some batch size tweaking and it barely fits into 8GB VRAM.

64k context is the minimum for Hermes agent, so a vision capable "agentic" model fits into a 16GB card. This is very impressive. I am currently testing how smart the model is and it does decently so far, had one looping issue it recovered after a lot of tokens, did some basic tool calling.

Ah, ok. I took a look at the 3090 numbers and they list 400 tok/s prefill, so if I normalize my expectations to that base line the numbers you posted do make sense. I haven't dug deep into that site's methodology, but their estimates seems way off. Especially since they don't take into account cache quant when deciding whether or not you can run a model. Overall I found that website a bit confusing, but maybe the UX just didn't click with me.

> The MI100 is roughly double the performance on Qwen 3.5 35B A3B Q5_K_M to the R9700 (462 token/s prefill vs 239 tokens/s, 217 tokens/s vs 118 token/s for inference)

Those prefill numbers look really low to me. I can run nearly that same model (qwen 3.6) at q4km with q6 cache on a single 3090 and get 2.3k-4.4k prefill and 100-170 generation. Just based on raw numbers I would expect the R9700 to land around 70-90 generation (about 2/3 of memory bandwidth of a 3090) and at least the same or higher prefill (nearly 3x FP16 TOPS on the R9700). That means the numbers really don't add up. Is the benchmark done with some special settings, e.g. parallel requests or with very low prompt length?

For those who, like me, had to do a double take on that number: https://www.businessinsider.com/openclaw-peter-steinberger-a...

Yes, $1.3M in token cost in less than 30 days and some days were even off-peak, if you can call it that with that insane scale that likely hides quite a lot of tokens in the lower bars.

HN thread: https://news.ycombinator.com/item?id=48159227

Without having firm data, I can see a few factors that are different. After the collapse of the GDR, it was easier for eastern Germans to move to west Germany than for Polish to move to a different country in the west. Mostly younger and educated people would have made that move, hampering future generations. With the Reunification also came the whole Treuhand issue which essentially sold off a good chunk of eastern Germany for pennies to western investors, because eastern investors had no capital. That meant the east lost out on the profits from its economy as they would accumulate in the west instead. Even today a large part of east German rentals are owned by western landlords or corporations. Then the industrial base of west Germany was setup far more for competing on the open world market with automotive companies in the NW (VW), SW (Daimler) and SE (BMW) plus the big industrial area Ruhrgebiet. So you naturally got an economic focus even after Reunification on the old BRD with the previous GDR requiring decades to hopefully catch up to the rest of the new country.

And a minority of those kids will get curious about the How and Why. Those are the security nerds of the future securing the networks against both the kids they were themselves and actual malicious actors.

Source: Early interest in wifi security, including in other people's networks, lead me down an education and career in security

In 2019 there was a talk about data mining the DB arrival data [1] (yes, this problem is nothing new). One of the takeaways was that on some connections you can actually buy a "Sparticket" (cheaper, but only valid for a specific train), but get it upgraded to a "Flexticket" (more expensive, can take any train on the route) for free. This works because a delay of more than X minutes removes the specific train requirement and some routes are nearly always delayed by at least that threshold.

[1] https://media.ccc.de/v/36c3-10652-bahnmining_-_punktlichkeit... (German)

Related, there is a stable way to detect whether your .exe is running under Wine and even which version by looking up the address of the export wine_get_version in ntdll [1]. Years ago I actually had to do this to work around some weird path bug when we were testing our Windows build under Wine (easier to setup Wine than a full Windows CI).

[1] https://www.winehq.org/pipermail/wine-devel/2008-September/0...

I still have to go through my watch list, the age old issue of not having my slides done before congress...

The 10 year of Dieselgate is interesting just from a "how bad is it really?" PoV, I saw the part about curves and other defeat devices already [1].

The Rowhammer talk is likely going to be great as well, I like Daniel's work [2].

The practical Cross-VM Spectre was interesting to show this is still a problem [3].

The opensource secure element was good for trying such a thing, but I wasn't that impressed with the content [4].

[1] https://cfp.cccv.de/39c3/talk/7MSRA7/ https://media.ccc.de/v/39c3-10-years-of-dieselgate

[2] https://cfp.cccv.de/39c3/talk/3JXAJJ/ https://media.ccc.de/v/39c3-rowhammer-in-the-wild-large-scal...

[3] https://cfp.cccv.de/39c3/talk/ATYLN9/ https://media.ccc.de/v/39c3-spectre-in-the-real-world-leakin...

[4] https://cfp.cccv.de/39c3/talk/9DYZXG/ https://media.ccc.de/v/39c3-lessons-from-building-an-open-ar...

Author here, happy to answer any questions you might have.

SteamVR works ok, but last I checked it still performs worse than on Windows. If you are feeling adventurous, you can try a FOSS VR stack [1]. It works for Steam games running Proton and when it works it provides better performance. I had some troubles with it, sometimes you need to switch versions or you get some artifacts in games, or some games just don't work at all. Good thing is, switching between FOSS and SteamVR is as simple as launching either first before starting the VR game in Steam.

I guess the Linux VR stack might get a bit of love from Valve for the Steam Frame, so things might improve in the near future.

[1] https://lvra.gitlab.io/docs/fossvr/envision/

At this point escalating, or threatening to, might be the better option. But I can't help trying to figure out how to solve a people/organizational problem with a technological solution.

Github is still famously IPv4 only. I don't know if there is a split between the SSH (if you use SSH to access the repos) and HTTPS (the tarballs) setup on their end, so maybe you get full speed on IPv6 and limited on IPv4 (or the other way around). Try disabling IPv6 on your end, if the speeds match then this might be it. If IPv6 is fast using an IPv4 gateway that tunnels via an IPv6 VPN might be a workaround.

I also had a similar problem a while back. Some speedtests showed more bandwidth than I could get in regular HTTPS downloads. I could get multiple downloads running at the same time that in total added up to the expected speed. In my case the line was just lossy enough (TCP retransmits in Wireshark) for TCP to never scale up its window size properly beyond a certain limit per connection. I verified this by running iperf in TCP and UDP against a gigabit server, UDP reached near full speed because it didn't care about a few lost packages. Working around that issue might be a bit harder, maybe [1] via [2] can provide some ideas to look into.

[1] https://github.com/apernet/tcp-brutal

[2] https://news.ycombinator.com/item?id=38164574

As much as I hate where this might lead, I can't help but amuse myself over a scene like this: You walk up to a bearded fellow in a dark alley and quietly whisper "Stallman..." only for him to quietly respond "... was right.". He then opens his coat for you to choose the install USB of your favorite distro (Arch of course!). He dutifully hands you the stick and a printed copy of the GPLv5 for you to hide in your coat as you walk past the telescreens back to your home.

That part also caused my tin foil hat to heat up. At least they get the credit of including it directly instead of adding it in a later revision that gets even less news coverage. It is hard not to grow cynical when you see this.

I am also worried about another detail:

> The states also want to prevent the circumvention of blocking orders by erotic portals ... using so-called mirror domains – i.e., the distribution of identical content under a minimally changed web address. For a page to be treated as a mirror page and quickly blocked without a new procedure, it must essentially have the same content as the already blocked original.

Note the part "quickly blocked without a new procedure" so there is a way to block sites with even less process and oversight. That just invites overblocking without accountability.

I managed to find some statistics on hull losses per million departures [1, p. 13]. Seems like indeed MD-11s have a highish rate of incidents by that metric compared to other types, even if they are not catastrophically less safe than other planes. That metric stacks the statistics a bit against cargo planes, which most (all?) MD-11s are now. These planes tend to fly longer haul instead of short hop, so you get more flight time/miles but less departures. There are also likely some other confounding factors like mostly night operations (visibility and crew fatigue) and the tendency to write off older planes instead of returning them to service after an incident. Plus these aircraft have been in operation long enough that improvements in procedures and training would impact them less than more modern types, as in they already had more accidents before these improvements.

[1] https://www.boeing.com/content/dam/boeing/boeingdotcom/compa...

At some point it comes down to probabilities. With so many flights going on, one in a million incidents become a certainty. For example UA232 [1] suffered failure in all 3 redundant hydraulic systems due to an uncontained engine failure. Any of the 3 systems would have been enough to retain control of the aircraft. Of course this lead to some investigations on why all 3 systems could be impacted at the same time and what can be done to limit failures.

Besides the technical aspects that flight is an impressive example of resilience and skill. Bringing that plane down to the ground in nearly one piece was essentially impossible and a one in a million chance in itself.

[1] https://en.wikipedia.org/wiki/United_Airlines_Flight_232

Given that the report only mentioned a single other seemingly related accident in 1979 I am not sure that objectively this is a reason to discontinue flying these planes. The fact that these planes have been in service since the early 70s is a testament to their safety and reliability in itself. Of course public perception, especially with the videos of huge fireballs from hitting one of the worst possible locations, might put enough pressure on airlines to retire the planes anyway.

I agree on the end of an era. Hearing something else besides just Airbus- or Boeing-something always gives me a bit of joy. Even though MDs and DCs are of course Boeings in a sense now as well.

I haven't seen that one, this video [1] includes a different angle taken from a vehicle on the airport.

[1] https://youtu.be/POKJUJk_2xs?t=342

Grounding all MD-11s and DC-10s is a major move. I guess it makes sense as a big factor was the fatigue cracks on the pylon (lugs), despite the pylon not being behind on inspections. I am wondering what the inspections of pylons in other planes will yield, likely that will determine whether the grounding will continue.

But beyond figuring out why the engine mount failed, I am very interested in what caused the actual crash. "Just" losing thrust in a single engine is usually not enough to cause a crash, the remaining engine(s) have enough margin to get the plane airborne. Of course this was a major structural failure and might have caused additional damage.

EDIT: It seems there was damage to the engine in the tail, even though this was not specified in the preliminary report, likely because it has not been sufficiently confirmed yet.

Had to check, but that is actually beyond what DNS allows. Labels (the part between dots) are limited to 63 characters. We could sneakily drop an s somewhere in there and then it would fit.

https://datatracker.ietf.org/doc/html/rfc1035

Also I think I triggered a nice error log in domaintools just now. https://whois.domaintools.com/downdetectorsdowndetectorsdown...

Would be great of Valve to just drop a Steam Machine Max++ with an AMD Ryzen AI 395 and 128GB unified memory. I know this is not going to happen, but SteamOS should boot fine on that SoC, so you can DIY a Steam Machine that also runs LLMs (albeit a bit slow) :).

I want to echo a previous comment of mine on this topic:

With the rise of mainstream-compatible, as in a standard gamer can get them running and use them with a similar frustration level as Win11, Linux first systems like steam deck, steam machine and even steam frame, there is a real, even if currently low, pressure for big publisher to support Linux/SteamOS. I somewhat hope/fear there will be a blessed SteamOS version that supports anticheats enough for publishers like EA, Epic and Riot to accept the risk.