suncore

Sure, when it's mature...

Zfs and btrfs will avoid corruption caused below the file system layer, not something like malware or misuse from a tired sysadmin. I run a tool called integrit that creates checksums and lets me detect non-wanted changes. I only run it on important stuff that does not change too much like photos and videos. Not fun to have to regularly check the log but it works fairly well. This could maybe be extended with automatic checking of the logs.

Working on everything from 1G to 6G, I can tell you for sure there will be a 7G whether we need it or not...

Not the right order if the optimization is a prerequisite for a positive business case. That happens more often than people think...

Not sure there is much actual profit in LLMs. It will be interesting to see promise meet reality, indeed.

How about an I-native org?

Marketing grab

If "dead" things look this much alive, imagine how hard it is to determine life on other planets. Real life could look much more dull than these things :-)

Cheap QLC drives become super slow when it is starting to get fairly full and starts garbage collecting (collecting SLC writes into QLC at maybe 10MB/s). IMHO this is not good enough for an OS drive.

Very easy to reproduce: 1. Buy cheap QLC drive. 2. Fill with Steam games. 3. Delete some steam games and download new games. 4. Watch write speeds tank to zero for long periods when downloading.

It's due to garbage collecting on very slow QLC NAND. You won't see it until the drive starts to get 60%+ full. Until then, the drive pretends it is an SLC with very fast writes, but then it starts to show its true colors. Yuck.

About the Lobster language used: The first thing I do when encountering a new language is look at the memory management, since what I want to do with a piece of code is usually build and manipulate data in a safe and efficient manner, so this is central. I am happy to see Lobster seems to be trying to take a new(ish) and pragmatical approach to memory management and that there is a whole document describing it in detail (https://aardappel.github.io/lobster/memory_management.html) which means the language creator agrees that this is important. Also happy to see the language seems to support fast memory management in a multi threaded environment, which is absolutely not self evident in many languages.

Build what you know you need now. Refactor when things grow. Doesn't have to be rocket science.

According to https://www.youtube.com/watch?v=b66ZZ05wKC0 this might end very badly very soon.

I turned off HDR. Much happier now that I can see what's going on on the screen.

24 fps looks like shit. Hurts my brain. Ain't turning off smooth motion :-)

There is an interesting discussion about the need for ray tracing in one of the later Digital Foundry videos. The argument goes that sometimes baked lighting is impractical due to the size of the maps and how much dynamic lighting you need. The latest Doom game is one such game where light maps would be 100s of GBs. But I guess most other games are fine with baked lighting.

Maybe the buyers started migrating to IPv6 when they saw how expensive IPv4 addresses are and there is a delay before they actually migrate. IPv4 addresses are way more expensive than I thought, upwards of $60 per address, jeez...

Splitting a piece of software into multiple pieces and shipping the pieces (dependencies) independently is sometimes a good idea, but it has its limits. Maybe the limit should be for dependencies which are very stable and used by many packages (libc, etc.). The hard line policy enforced by Debian here obviously is not working. Happy to see other distros solve this better. This might become really problematic for Debian in the future.

That should be 16 IPv6 /64 networks, right? Which means Azure gives you a /60 prefix, I guess?

Data (state, context, whatever) is more important to structure than code. Make sure your programming language lets you structure data the way you feel is natural. The code comes later and the main function is to massage the data. At least this is how I usually think about it, but everyones mind works differently... :-)

DPDK/SRIOV eats the interface so Linux kernel does not see it at all. The above diagram is kind of irrelevant as it would look like a giant bypass.

I loved directory opus so much on the Amiga that I eventuelly wrote not one but three variants of it for Linux, albeit much simpler. The latest one I still use and maintain and you're welcome to try it at https://github.com/suncore/dflynav

Email issued by your government, in addition to authentication services needed for online banking etc.

Here's a few observations (after long time experience and involvement in research around technical debt):

1) It is impossible to avoid gathering technical debt. The code will deteriorate in one way or another. You need to prepare to fix it since you can't avoid it.

2) It is so extremely difficult to make a correct "risk assessment" on technical debt so you should avoid doing so at all. You will just end up arguing all day on the merits of clean code/architecture vs feature growth. Instead, keep two backlogs and reserve a set amount of resources on each, e.g. 20% on reducing technical debt and 80% for product features and other development.

3) The "cost" of reducing technical debt is actually negative. That's the whole point of working with it, to increase development velocity.

Ok, I'm biased since I was a kid during the 80s but two things strike me: 1. I still love the design language of the Walkman with brushed colored metal. Why can't we have that today? 2. It strikes me that a lot more thought and engineering has gone into these products compared to today. Most things today are just cheap all over with pointless design without function.

Sceptic here...

VR goggles are too anti-social on the local scale. Have kids? Dog? Spouse? Hard to see they will accept that you shield yourself off completely for long periods of time. You won't even see them coming when they start to grow tired... This is a fundamental flaw.

Then the metaverse... What is the usecase? Why is it fun or why is it useful? It might be cool for a while, but so are lots of other MMOs out there...

I think the main difference (benefit?) is that Nim has the convenience of a garbage collected language while retaining good and predictable performance (e.g. via ARC/ORC and thread-local GC). Rust has no GC so requires more from the programmer. Personally, I'd rather use a GC language to have less complexity in the code even though I have to spend some more time learning to use the GC correctly.

What ZFS does here is not enough for me. I need to be alerted to changes done also above the file system layer, like by malware or accidental deletion etc. Only way I have found to solve that is to have checksum tool above the file system. If something is wrong, I restore from backup, so zfs does not give me anything...

After many years of being an architect I would suggest getting really familiar with two concepts: Separation of concern and (reduction of) Technical Debt.

Both are important concepts that you will need to promote as an architect and the whole point of it is to reduce the total complexity that is facing developers during their daily work (so they can focus on the important stuff and not be bogged down with irrelevant stuff...).

I think it might actually succeed to replace TCP. There are a bunch of benefits. There is a great video here about it that you should also watch before passing summary judgement: https://www.youtube.com/watch?v=idViw4anA6E