Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)AO
Posts
0
Comments
1,229
Joined
2 yr. ago

  • I mean, in theory, coal burning could be made clean. Capture the carbon out of the exhaust, collect it into a solid block, bury it, done. Problem is the power plants will only pretend to do this, and not actually do it.

  • Hardware tokens are specifically designed to resist copying. Any means of copying it would be considered a security vulnerability.

    Bits rot. A hardware token kept in a bank vault may or may not still work when I need it 10 years later, and there is no reasonable process for regularly verifying the integrity of its contents. Backup drives' checksums are verified with every backup cycle, and so are the checksums on the file system being backed up (I'm using btrfs for that reason).

    Hardware tokens are expensive. Mechanical lock keys are not.

  • The worst thing that will happen is the attack-vector-spreadsheet, itself, might be compromised. Or Microsoft’s cloud computers, which are, again, not your computers.

    But they house my information, and goodness knows Microsoft will not compensate me when my information gets leaked through no fault of mine.

    No cloud, no how. Keep it local.

  • Sure, in theory, but doing that would require advanced knowledge, it’s not something a random shady seller on eBay would do.

    No. Writing the code to do that would require advanced knowledge, but once it's written, any common criminal can use it.

    With skills like that, they could easily get a high paying job, or if they really want to be a criminal, a better option would be getting into something like phishing or cryptolocking, which, skills wise, is easier than writing a custom bootloader.

    They could use the compromised phone they sell you to phish or ransom you.

    Which is why the first thing you should do is do a factory reset, update the phone, and do another factory reset. Or an even better option would be to just flash the factory firmware downloaded directly from the vendor.

    All of those only work if the software already on the phone allows them to work. Factory resets, updates, and USB flashing are all implemented by software.

  • Nobody else solved the problems ?

    Nope. Before PA, we had ESD, aRts, and NAS. All of them had horrible latency. They could play a ding at approximately the right time, but everything else was utterly beyond them. They were also mutually incompatible and there was no reliable way for apps to discover which one, if any, they were supposed to use.

    Other then hotplugging audio

    And multiplexing multiple audio streams to a single input/output device with reasonable latency, and moving an audio stream to a different device, and individually controlling audio streams' volume, and sending audio streams over the network or Bluetooth with reasonable latency, and…

    Yeah, no. Linux audio sucked before PA came along. I know it did because I was there, struggling with it.

    Wanna know the alsa bug on my audio card ? It calls master volume “master center” instead of master.

    Okay? I didn't claim that PA never had any bugs of its own. All software has bugs.

    And it’s done properly only now with pw. PW… where the dev asked for advice from professionals instead of knowing it all. PA is now x11

    I also didn't claim PA is perfect, nor that some newer, better system will never come along. I claimed that PA is vastly better than what came before it, which is correct, and I have the experience to prove it.

    And what about making udev locked down to one init ?

    Red Hat chose to cease maintenance of the separate udev and focus its efforts on the systemd-integrated udev. Others took up the task of maintaining a separate udev, and called their fork eudev. I'm not seeing any problem with this.

    SystemD didn’t make computers boot faster the, say, upstart.

    Upstart expects daemons to SIGSTOP themselves to signal readiness. That is not a sound design.

    I don't know if there's anything else wrong with it, as I have never used it myself, but I have yet to hear any well-reasoned explanation of how it's better than systemd.

    Logging does not have to be tied to it

    It isn't. You can still use a syslog daemon with systemd if you want.

    as there are even established protocols for it.

    Yes, and have you ever tried to implement them? I have. They suck.

    • Extremely easy to format or parse incorrectly.
    • Non-extensible, leading to a proliferation of dialects, making parsing log records a minefield.
    • No way to include line feeds or other control characters in a log record.
    • There are two different, mutually incompatible protocols, only one of which is described by IETF RFCs. The RFCs describe the protocol used for logging on another machine. There do not appear to be any formal standards for the local logging protocol used on /dev/log. There isn't even a specification saying /dev/log exists at all.
    • No structured data, outside of an obscure RFC that has, as far as I can tell, zero implementations.
    • 1024 bytes max per log record. If you want to include a stack trace with your log message, too bad, not happening.

    And that's just the log record submission protocol. The storage format has all of the above problems except the one about /dev/log, and several more:

    • The only real standard for how log records are stored is that they're delimited by line feeds. That's it. Everything else is configurable and therefore unpredictable. Parsing them reliably is basically impossible.
    • If the syslog daemon has a hiccup, log records can be smushed together without a line feed delimiter, making them extra-impossible to parse. There is no checksum or length field with which to automatically detect that this has happened.
    • Log records are typically separated into numerous different log files. Don't know which one your program's log records are ending up in? Here's grep; good luck.
    • Owing to the aforementioned parsing difficulties, there is no reliable way to filter logs by program, by date, etc. Here's grep; good luck.
    • The systemd service (or equivalent) from which a log record originated is not recorded in the log. Better hope your program doesn't use a different name than the one you expect it to use. I know of at least one that has this behavior: cron.
    • There is no record of whether a log record was generated during the current boot or the previous one. Want to only see log records since the last reboot? Here's grep; good luck.
    • Did I mention there are no checksums? Because there are no checksums.

    This may have been acceptable in the 1980s, but it doesn't hold a candle to the systemd journal. Good riddance.

    I should be greatful… for the one true way

    You should be grateful for software that is vastly better than its predecessors with no significant drawbacks, yes.

  • 10s of Millions of people in the united states live in multifamily housing.

    And every last one of them is made to abide by unnecessary and cruel rules, like prohibiting the use of air conditioners because they change the exterior appearance of the building. Renters are also getting fleeced like sheep and regularly evicted to make room for richer tenants.

    Building more non-single-family housing will only exacerbate this problem, not solve it.

    We can certainly use better and actual proper public housing options like in places like the netherlands, and better renter protections to keep a landlord from upping your rent too much, but thats all the more reason to push forwards.

    No, it's not. Those protections have to happen first, and in this country, they never will.