drpixie

Similar. I though it would be a media file format ... containing audio, video, tags, pics, etc.

Hmmm. I went to the doco hoping for something about the file format :( No doco for me. I guess that would be too old fashioned.

It seems to be "read the code" or nothing - which is fine until they update the code... It's great (probably should be mandatory) to have a reference program, but if they're promoting it as a container format, something along the lines of an RFC would be helpful.

And the author specifies Z85 only for 4 byte chunks of data - not all data comes in 32 bit chunks. If the authors want Z85 to be widely used, specifying padding would be helpful.

Anyway, it all seems a bit https://xkcd.com/927/

> You can build gates, which is nice for switching packets, but how do you store data?

Logic gates can be the fundamental building block. So if you can build logic gates, then you can use those to build flip flops (the basis of static RAM) which store data. Might not be the most efficient way (depending on your requirements) but it can be done.

https://en.wikipedia.org/wiki/Flip-flop_(electronics)#D_flip...

I've been using log2ram (github/azlux/log2ram) and been happy with the results.

It mounts a ramdisk on /var and only occasionally copies the logs from ramdisk to SD card. That way I can still see all the logging without hammering the SD card quite some badly.

Yes. And I monitor my network link and automatically power-cycle the modem, if the worst happens. (Which is rare, but the network link has been the source of most of the few problems I've had.)

And use a wired network connection for anything important!

And the intriguing load/store scheme.

There were no LOAD or STORE instructions. Instead there were "address" registers (18 bits wide), matched to each "operand" (60 bit data) register.

When you updated an address register, that memory address was automatically read into the correspond operand register. Except for the last couple address registers - updating them performed a write from the corresponding operand into memory.

By our current way of thinking, it seems arse about. But it worked well when you understood it, and apparently improved concurrency. Loads and stores became sort-of transparent. (Remembering that memory was as fast, sometimes faster than the CPU, so a few instructions saved was worth the occasional unnecessary load.)

See "Design of a Computer, The Control Data 6600" by J E Thornton.

And even more specifically "On the Costs of Linux Syscalls on Intel processors".

I would like to see this extended to other processor families.

Wrong domain name - bcdclock.net is available.

No idea but it did generate a reaction ... Is she a Hollywood spy/hacker? What system she breaking into? (Maybe it's the dark scene and backlighting :) )

yup - and because the number feature interactions is exponential with the number of features, things get much, much worse as the number of interacting features increases.

> with the right programming

:( That's the bit we still don't have right. Apart from a few special cases, we really struggle to use a small number of threads, or a GPU, without enormous amounts of effort - let alone distributed processors.

I'm sure part of the problem is we depend on high levels of backwards compatibility with systems assuming mono-processing ... but I'd like to think there is a way.

Now if someone came up with a really usable and general model for software across distributed processors...

Perhaps add "Docs must be more than screenshots or follow-the-monkey instructions". If it's not appropriate to explain what the system is doing, it is then appropriate to link to something that does explain it.

Docs that say/show anything like "Select Enable VTd to enable the VTd function" are useless docs. I won't bother providing a list of docs that do exactly that, but start by looking at your BIOS help!! I think we can assume that I understand "click" and "enable", but we should also assume that only the project engineers understand the acronyms and special functions. How about "The VTd function (Intel's Virtual Technology - Direct IO) permits virtual machines to do IO with fewer buffer transfers. Virtual machines may run faster, but could corrupt disk."

But the fact the manufacturer wants you to replace the part, is not evidence that the part needs to be replaced.

I've certainly had lots of login probes at common non-standard ports - 22+n for easy to remember n.

But it's nice to have the logs reasonably clean, makes it easier to see real problems.

Similar. It's been a good experience and no more or less successful than gmail. I've had a couple of delivery hassles (easily fixed) but plenty of stuff gets lost in gmail's or outlook's filters. So at the end of the say, not much difference in usability, but much more interesting :)

I've been using mailinabox and it goes to a lot of trouble to provide correct DKIM etc, which I'm sure helps avoid deliverability problems. (Thanks Josh.)

If you've got a sensible ISP, you can host from home just fine.

You'll need an ISP who can permit traffic on port 25 (usually blocked for domestic connections); a "static" IP address really is necessary (a fixed address, not behind a NAT); and your ISP must be able to handle your reverse DNS entries (IPv4 and IPv6). Any ISP who can handle commercial customers will be able to do all that. And a UPS power source is highly recommended.

In some ways, email is a good place to start self hosting. It's based on store-and-forward, so you can be down for a while ... and when you come back up, any stored email will be delivered :)

But be aware of security, and don't let your server become a spam relay!

YES - The ribbon UI has been around for ... what, decades, now. And it's still less usable that regular menus :(

Over the last few years it's been moving away from providing maps. Seems like management only want to provide advertising, and follow-my-directions ... It feels like "do what I tell you and buy what I tell you", not what I want from a map!

I now routinely install fake-ubuntu-advantage-tools.deb to remove Ubuntu "Advantage". It's an empty package that satisfies the dependencies.

I also remove some of the crap that Ubuntu put in /etc/update-motd.d. From memory 10-help-text, 50-motd-news, 88-esm-announce, 91-contract-ua-esm-status are pointless and annoying.

See https://github.com/Skyedra/UnspamifyUbuntu

Precisely. Why go for the complex, expensive, and fragile solution when better shades (and maybe proximity/motion sensors) would do the job?

An important function of language (and accent) is to distinguish between groups/classes of people.

Makes it easy to tell if someone spent many years at school, or learnt a "trade", to tell people from one (monied) area from a less affluent part of town.

For this function, "correct" or "incorrect" use of apostrophes (like an accent) is serving a very clear purpose - telling others your position in society.

Perhaps ' is pronounced as a small tongue click?

Anyway, a well organised big project is a collection of related small projects :)

And what's good for one small project is likely to be good for many small projects.

And of the same vintage, hands up who remembers "line printers" (hence the device name lpr).

They had a row of solenoid driven hammers that would belt the paper+ribbon against a spinning drum or chain that was embossed with metal characters, typically 132 rows of 96 characters. The drums/chain spun very quickly. Big printers could print several thousand lines per minute (say a full page every 2 or 3 seconds, and much faster for empty pages.)

They were Rather Loud - all those hammers belting a spinning metal drum several thousand times each second.

A couple of tricks. Printers were not bolted to the floor. So imagine if all the hammers struck at the same time ... bang ... pause ... bang ... pause ... and the printer would increasingly wobble forwards and backwards, walking across its platform! The letters on the drum were staggered, so a row of "--------" wouldn't cause this, but rows of ABCDEFGH... would.

They used fan-fold paper, and blank lines/pages could be ejected VERY quickly. There was a built-in a limit on pages/minute but if you produced the right (wrong) output, and someone left the printer lid open, the stream of paper would flow straight out of the printer and start to bunch up in the air!

See: https://en.wikipedia.org/wiki/Line_printer

And a early one operating: https://youtu.be/FiEGoVzmyvs

And make people better programmer it did :)

It's very usual now (and for the last 20-30 years) to see programmers live a loop of more-or-less randomly change code and see if it runs, repeat... Their code will eventually run, and pass the tests, but will be terrible - not understandable, inefficient, and break when confronted with reality or better tests.

When it was quicker and easier to think about the code, than play with it, people generally produced higher quality code.

Reaching a "reasonably close" upper bound estimate wouldn't provide proof ... probability maybe, but not proof.

Am I the only person who thinks the whole thing is a joke, a bit like brainfuck - https://en.wikipedia.org/wiki/Brainfuck

Outlook webmail is pretty bad. Not only does it do the "... days ago" thing, but it wants to show what it regards are important at the top. So you get two partly duplicated lists, partially shuffled together - it's horrible x 2.

Absolutely agree.

If they think they can make a better file manager, great, go ahead. But including transports in the file manager means that remote data only looks integrated, it isn't actually available to local apps.

Or (just as bad) they'll decide they need a copy-to-local and copy-back-to-network mechanism, which will work for some files opened by some apps but not all. Arghh.

Nemo (under Linux) does that for some protocols (eg. Android media transfer), and it is very annoying, especially as there are already FUSE drivers for (at least some) such protocols. In practice it means that the only thing you can do using Nemo is copy/move files around.