v1ne

Oh, wow. That's a pity. I mean, you're down to the battery time of any random x86 laptop.

I usually get barely a working day out of my corporate MacBook Pro M1 with Corpo Security Special Sauce, CLion and Teams. But I have to kill CLion when it gets too crazy (i.e. often). Do you have any insights from Activity Monitor on who is draining the battery?

My biggest offenders: - Symantec Data Loss Prevention Agent (x86 Emulation) - $Corporation App Store (I never use it, don't know why it burns CPU time)

This corporate "security" software is the essence of everything that's wrong with a corporation.

This JH7110 is from 2021. Some specs: https://www.cnx-software.com/2022/08/29/starfive-jh7110-risc...

1.5 GHz CPU core frequency, some old RISC-V cores while we're still waiting for cores with decent single-core performance to compete with modern desktop processors.

Sorry, but for me this board is dead in the water, unless you can't use ARM/x86 for political reasons.

How do you recreate the rich interaction that you have when you meet somebody face to face, when you have to use (a) Amazon's crappy Zoom clone (forgot the name, they forced their applicants to use it, too. It's horrible and couldn't even cope with my German keyboard layout) or (b) some text-based messaging?

Even if you replace (a) with a proper video chat solution, it's a much, much narrower channel than real interaction between people where people perceive all these tiny non-verbal signals like changes in posture, gestures, mimics, breathing, and you can actually point a colleague to something with your finger, all in real-time.

So, no, from my perspective, online interactions are very sad and simple, compared to real-world interactions.

I work in a low-latency field, maybe I'm more sensitive to latency. But I find all those narrow communication channels a nuisance. I find it frustrating to have to rely on a variety of tools to achieve collaboration: Chat, video chat, digital whiteboard, code sharing. There is so much friction, at least in my workplace, to switch between those tools or to combine them. This can surely be improved, but there are things that naturally can't disappear, like latency.

Honestly, I'm dreaming of a place where people have to work from the office again. So I can have a Kanban board with paper cards on a board again, for everyone to see, touch, and write on.

OMG, this is how I started programming. I was so happy creating small helpers with this toolchain, e.g. something like Spotlight to launch programs with with a hotkey + the name of the program, on Windows 98.

Yeah, that's also how my long journey with induction cooktops started. My main grief with the induction cooktops was the ergonomics: Most touch surfaces on those cooktops require at least 2 touches: select the flame, then adjust the power. I don't know, that completely breaks the interaction for me. I want something to directly adjust the heat on every single one of the flames, especially when something starts to boil over or fries too fast. In addition, touch often wouldn't register on those, so I have to press longer or harder, both of which is even more inconvenient. No, even more: it outright sucks.

Well, and after years of searching, friends recommended me the AEG models, like IKE64450XB (here in Europe). And honestly, I was happy with the touch surface ever after: It reacts quickly enough and I can modify every flame at an instant. I don't even get a penny for this, I'm just satisfied. So, yeah, touch can be good, like on a smartphone, even on household devices.

On the other side, it's really hit or miss with these touch UIs: I also have an combined washing machine + dryer from the same brand and there I need to press each touch surface for at least half a second, and not touch the metal case of the machine, otherwise the touch wouldn't register. Then, the UI would sometimes hang, but still register touches, playing them back once it has caught up.

Using an M2 SSD instead of soldering the chip on board has more implications: PCB gets physically larger, and takes more power or has less performance talking to the SSD. Heat transfer is also worse. I completely understand why they go for a soldered SSD chip.

One way of true environmentally-friendly innovation could have been to find a way to attach the SSD chip so that a user could safely replace it, though, with little additional space.

Thank you for the pointer! ConTeXt looks pretty promising.

It's a pity I feel because microtype is from 2004. That's 20 years ago. Yet, typesetting on the web is still ... not there? I think there's a lot of potential untapped.

Also, the full feature set of microtype is only supported with (Pdf)LaTeX, but not with the newer XeLaTex, meaning that in order to get your favourite fonts to work with PdfLaTex, you have to do a hilarious amount of work to translate an OTF font into specific cuts in MetaFont, the LaTeX font format, and so on.

I mean, I understand that things get pretty tricky once you try to integrate such schemes into a font renderer. There's other scripts than just Latin, with probably very different rules, there are different font sizes, text sizes, etc. A lot of variables to take into account. A lot of variables that were constants when typesetting on a page. So the problem is now more complicated than in the past.

This 2019 talk is so hilarious. 200 $/day with ads for apps which are so awful.

Yet, the world has changed and with the advent of AI, let's see who wins: The people who churn apps out like there is no tomorrow (of course, limited to 15 apps a day) or the gatekeepers.

Nice to see we're getting there again and that people care about typography.

Yet, the optical margin correction looks mechanistic and only concerned with symbols, not with characters: The "Y" at the start of the first line doesn't move a bit, even though it's clearly optically too light on the left. The next three lines all start optically pretty heavy with a bar. So I'd nudge to "Y" to the left.

I think it's just a pity that LaTeX with microtype is still the pinnacle of automatic typesetting, after all these years. I really enjoy good typography, but the Web, App and even Desktop world seems not to care about such details, apart from a few programs like Ableton.

The email thread continues. Linus later responded with:

>No, but I'm not a lawyer, so I'm not going to go into the details that I - and other maintainers - were told by lawyers. >I'm also not going to start discussing legal issues with random internet people who I seriously suspect are paid actors and/or have been riled up by them.

Which I find pretty concerning statements, quite a disservice to the community. It's a global community, and here the maintainers take some action without explanation. They don't even have a communiqué at hand to tell people what this action is, why it was taken, and which alternatives were considered but rejected. This is the bare minimum that I expect of the maintainers of a piece of software that is very critical to many millions of systems worldwide. Counting on the goodwill of users is not acceptable for an operating system that underpins the security of people's computers.

The article is a snapshot of the discussion that's still happening on the mailing list.

Linus later responded with:

>No, but I'm not a lawyer, so I'm not going to go into the details that I - and other maintainers - were told by lawyers.

>I'm also not going to start discussing legal issues with random internet people who I seriously suspect are paid actors and/or have been riled up by them.

I agree, people often underestimate the complexity of a browser and its ecosystem. Yet, I find it valuable that people question the merit of all these additional layers, especially those added by JS frameworks. What do they yield? Do they allow you to more quickly develop an application? Are the applications better than before, by any metric?

I'm pretty sceptical because coming from real-time & desktop programs, I find UX on most web apps I use leaves a lot to be desired: I regularly see state inconsistencies when I go back & forward in my browser, I cause race conditions by quickly editing fields, fight with input validation missing my input, and just die a slow death because the page is just slow. I would have assumed that frameworks existed to remove all these burdens from developers. Yet that such issues persist so stubbornly for over a decade shows to me that somehow, even such simple and recurring tasks as providing and validating forms are not properly solved by those frameworks (or the field is full of people that don't know how to use them properly? Then, why is using them correctly not easier?).

I'm not a web dev, but I see a conflict between server-side HTML generation and a local-first application. ;)

I think there's 2 distinct use cases here: a) a classic "web-site" that people "visit", interact with and leave b) an "application" that people (in the past would have installed and then) use over a longer period of time that needs to persist and sync state

Case a) doesn't lend itself to local-first, because it's unpredictable which information the user wants to query (think of Wikipedia – I don't want to download all of Wikipedia before reading an article). Yet, I still find it important that the website renders quickly, which I guess means removing all the layers of JS, as you described, and returning HTML from the server. Or replacing the JS frameworks with something much more light-weight and asking what really needs to be done there. I'd aim at 100 ms page loading time (without initial network delay).

Case b) is the prime case for local-first, which I would phrase as a grumpy old man's "just bring back programs like we had in the past (immediate response, data is local), and add multi-user sync on top". This means reaction times in the ballpark of 16 ms. I'm very happy that the local-first movement brings this experience into web apps.

And about people re-implementing TCP: I first thought you referred to QUIC. Because it's also a non-C implementation – in userspace. It is better in some scenarios, but also much more ineffecient and slower on high-bandwidth links (cf. e.g.: B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, G. Carle. 2023. QUIC on the Highway: Evaluating Performance on High-rate Links. In Proc. of IFIP Networking Conference (IFIP Networking)).

I also still use FreeBSD on my NAS. But after many years, the desktop experience was pretty sad and made me switch to Windows + Linux for my hardware tinkering. On one side, the lack of manpower shows in many places, unfortunately. I'm talking modern WiFi, GPU support, or power-save mechanisms. On the other side, many Open Source projects only support Linux and getting their projects to compile + run on FreeBSD was a pain, too.

I mean, in addition to what kev009 mentioned, FreeBSD has so many great things to offer: For example, a full-featured "ifconfig" instead of ip + ethtool + iwconfig. Or consistent file-system snapshots since like forever on UFS (and ZFS, of course). I never understood how people in a commercial setup could run filesystem-level backups on a machine without that, like on Linux with ext4. It's just asking for trouble.

So, I'm happy to see this thread about FreeBSD here! Maybe we can make the Open Source scene a bit more diverse again with regards to operating systems…

We have a saying in German: A bad worker always blames their tools.

Excel has many quirks, but I'm still very grateful that it exists, for quickly putting together some numbers and still being able to change the inputs to my formulas.

Oh, thank you for the offer! I'll pick it up again and update the PR. Haven't looked into it since then.

I found the OLS, especially with the Demon Core, a really neat piece of hardware.

I don't know. My experience as a contributor to Sigrok was sad: I significantly improved a driver and wanted to upstream those changes, but was met with "well, the maintainer has little time, can you slice your changes into smaller pieces?", and honestly, after a months of doing that, waiting weeks for feedback, explaining things, I lost interest. Also, with time, I honestly don't remember some details of the changes beyond what's in the commit messages.

I also found the style of the code quite antiquated, without any wish to change that. But that's my taste.

So, in the end, my work on that driver felt wasted.

Hmm, interesting. We also have a policies imposed by the Regulator™ that leads to us inspecting all web traffic. All web traffic goes through a proxy that's configured in the web browser. No proxy, no internet.

Out of curiosity: What's your use case to use ZScaler for this inspection instead?

Oh, sure there is! https://learn.microsoft.com/en-us/windows-hardware/drivers/n...

I don't get why the author blames bad drivers on the standby mode. I remember similar issues with S3 back then. You had to jump through many hoops on FreeBSD and Linux to make it work without draining your battery while still being able to resume from standby successfully. Disabling some drivers, but not others, etc.

Thus, a faulty implementation of a device or driver is not to blame on the standby mode. FWIW, Modern Standby works fine on my Thinkpad X1 Titanium Yoga with Windows 11. The only device that drains more battery than necessary if not disabled is the Qualcomm WWAN modem. That stops once you disable it, like in the "good old days". So for me, it's nothing negative, but actually adds convenience because with Modern Standby, my device goes to sleep and resumes much faster than the devices ever did with S3.

Modern Standby enables much faster return from Standby. You open the lid of your device and it's there. That's not the case with S3. I find it adds a lot of convenience.

No, it's not. We need less shoddy practices to develop software, e.g. mandatory 4-eyes process for security-critical changes, thread modelling, and maybe more Hardware Security Modules that encrypt critical information.

And if you need a second factor, I'm sure any smartphone-based TOTP will do. People already guard their smartphone well. No extra key fob needed.

What a blast from the past. WindowMaker served me well for many years, mainly on small screens. But once I started using multi-monitor setups, I switched to i3.

One thing: WindowMaker is easy to use yet full of options to customize the appearance and behaviour of windows, per-application and per-window.

Yet I think its killer feature for many years was the huge (64x64 pixel) "dock apps". There, you could put widgets with a ton of nice functionality, such as WiFi status, mailbox, disk monitoring — or just a clock. I don't remember if NeXTStep/WM were the first to offer those widgets, but I remember being a fond user of them.

Hmm, it's really nice that they fixed so many complaints. But honestly, reading the errata sheet, I had to chuckle that Dmitry didn't tear this chip to pieces.

I mean, there's erratums about obscure edge cases, about miniscule bugs. Sure, mistakes happen. And then there's this: Internal pull-downs don't work reliably.

Workaround: Disconnect digital input and only connect while you're reading the value. Well, great! Now it takes 3 instructions to read data from a port, significantly reducing the rate at which you can read data!

I guess it's just rare to have pull-downs, so that's naturally mitigating the issue a bit.

As somebody who has done both, there's certainly a lot of similarities in how you write software.

I'm talking about real-time audio, though. There's also just audio playback (Pro Tools, e.g.) which tolerates much higher latency, but enables higher audio fidelity due to larger buffer sizes (e.g. in compressors to enable look-ahead) as well as more clever algorithms (which are often prone to latency spikes, such as a "standard" FFT, if you want a very simple example).

Both, finance and real-time audio, differ in their time scales, but more in the breadth of their time scales: real-time audio is often between 1–50 ms (yeah, we try to keep it below 10 ms, but that's tough to do in a complex setup. I've seen artists often compromise and increase buffer sizes (== latency) to accommodate for their complex virtual instruments and filters), finance in ns–ms (it's not HFT anymore at a certain point, sure, but those HFT architectures also have a layered response, with FPGAs being quick but simple and more complex strategies having higher latency; also, if you're e.g. asked for a quote on a bond, it's not a shame to take 500 ms to think about a price, because those trades are bigger but slower).

You also mentioned the consequences of missing a deadline. Well, indeed, I've seen this variance to be less of an issue in finance (we're only caring about xx µs, so I hesitate to call myself a HFT guy) than in real-time audio. A click in a live set is a no-go. A crash of your DAW is fatal, that's it with your live set. Nobody dies, but people will be very upset. I've seen real-time audio being obsessed with being reliable and keeping the variance in latency really small.

In finance, I've seen it more that people kind of accepted that variance was huge because there's some hidden allocations in a system. Hoping that those stop once the system is warmed up or that they rarely occur on a critical trade. As a side note, in finance I've even heard this well-known HFT firm: "Well, it's not the end of the world if your process crashes. If you can restart quick enough."

It's also that in finance, your data is more heterogenous: Real-time audio has audio (isochronous, homogenous buffer of floats), MIDI (asynchronous, formerly small events), parameter changes (asynchronous, often just a float) and config changes (changes the topology of your audio processing graph; enjoy to transition from A to B without causing an audible glitch). Finance has processing graphs that only process asynchronous data (heterogenous market data, telling you what's on the order book of an exchange; trade data for which trades you performed with your orders and quotes; symbol data when new securities appear or change (historically only with the start of the trading day); pre-computed steering data for algorithms and/or data from third-party data sources).

Thus, the processing graphs of both differ in the data that's transferred as well as in the structure and domain. In finance, there is no regular tick-based processing. You have to accommodate a very varying amount of data per time period, whereas in audio, it's a very regular pace and the amount of data is often the same (± activations of voices in instruments).

Real-time audio has plugins, though. And those, from experience, do whatever you can imagine. Plugins are great, from a creative perspective, but the craftsmanship is of very varying degree. I bet I'll even find a plugin that draws the UI from the real-time audio thread.

Any other experiences from the real-time realm?

Is that really what companies have to do to "trust Windows"? From my experience, it's rather driven from the need to look compliant. Thus, managers without in-depth knowledge decide to buy "endpoint security solutions", the more the merrier, deploy them to your machine, and that brings things down to a crawl.

Why to a crawl? Well, I've witnessed multiple antivirus products go bezerk on your dev folder if you compile C++. Turning them off for this folder increased performance by a factor, which is what's typically done and completely subverts the purpose of these products. Also, I witnessed a certain product with a bird of prey that would run for hours and then just crash on a directory with a few million files.

This combination of sub-par quality of "security" products and performative deployment of endpoint security is a bane, at least for me as an enterprise software developer. I don't see Microsoft being primarily at fault there.

Autodesk EAGLE (formerly CadSoft) has a free tier (EAGLE Free) and it's a pretty decent layout program! I made numerous layouts with the standard license when it was still owend by Cadsoft and I found it comparably easy to use. I found a lot of the EDA software had either a very steep learning curve at the start or catered to "professional" workflows such as having different persons that do the schematic and layout that don't matter to me at home. For example, Eagle offered forward-and-backward connection between schematic and layout for a long time, whereas Kicad didn't. Meaning if I made a change in the schematic, I had to jump through hoops to get a netlist change into my schematic. EAGLE was much more focused on the workflow of one person doing the schematic and layout, I felt. Much closer to "getting the PCB layout done", with an easy parts editor to create custom parts etc. The flipside is that it breaks down quickly when you have more than 2 layers, I think. I don't remember any easy tools to e.g. route waveguides or equalize pairs of differential tracks.

But these days, give Kicad a try. Since CERN poured resources into it, it became a very capable EDA tool.

Well, maybe there's a deeper truth to qp11's statement:

I completely agree that moving to the tech city _du jour_ caters to the demographic of mid-20 "anywheres". Having a family, long-term friends or obligations such as elderly care rules you out. Or god forbid: A time-consuming hobby or in general something apart from work that gives meaning to your life.

And that's exactly the point! You only get those high wages when you put in the 60–80 hours a week (or 40 very focused hours a week) that you can spend if you live for your work. To the employer, such dependent, driven employees are very valuable. Much more than some family father who comes in for 20 hours a week and is often tired and just wants to get back home to play with his children.

It's been a pleasure to work at Ableton and to be at Loop. Gerhard as a co-founder always had an open ear, and the company deeply cared about its employees. And Robert provided valuable guidance from an artistic perspective.

I think the way Ableton works is responsible for a good part of Live's success: Treat people with respect, as something valuable and unique, and they will create an awesome product. There's a lot of attention to detail, a lot of dedication towards the artists that use Live every day. I mean, in the end, Live should not only enable very different people to create their own unique sound and music, but also work reliably, on stage, in real time, on a desktop OS. There isn't much talk about that, but DAWs are pretty complex, tightly coupled pieces of software, due to those requirements. There's a lot of unsung heroes.

Anyway, I'm grateful for all the lovely people I met at Ableton, for what I learnt, on a technical and social level, and the trust that was put into me, by giving me quite a free hand over a few subsystems of the software.