AsyncAwait

> Wikileaks made a request to the US government that it had to know the US government would refuse (for the reason I gave in my other post in response to you upthread). It did that so it could disingenuously claim that it gave the US government a chance to protect people's names and the US government refused, making it seem like it's the US government's fault

It's the U.S. government who committed war crimes here and used secrecy to conceal their crimes. Of course it's the U.S. government's fault. The option to not commit war crimes and use the secrets act to conceal it was there. They didn't take it.

The U.S. Government proved it will use 'top secret' to hide not only information that is actually top secret but also information that is embarrassing. This would be a pretty clear motivator for the Pentagon not to respond and for WikiLeaks to go ahead with the publication.

> Wikileaks could have published that information without publishing anyone's name.

No. Names as such are vital. It lets you know WHO needs to be held accountable. Most leaks are published with names in them. There are names that the U.S. government could have suggested (not demand) to be redacted and WikiLeaks could have agreed to either some or all of the requests. They refused to cooperate. It's pretty clearly on them.

I also love how the people exposing war crimes are getting more heat that the actual war criminals who never spent a day behind bars. Speaks volumes.

> Wikileaks is not a journalistic organisation because it lacks the editorial expertise, ethics, and resources essential to carry out responsible journalism.

There's (luckily) no exams (yet) for what makes a journalist. Someone who has a blog is no less a journalist than anyone at a national newspaper.

> They have to rely on real newspapers or the pentagon (!) to do it for them. It’s no defence to say: we tried to get other people to help us do the right thing

Actually it is. That's why intention is regularly taken into account in court cases and it shows WikiLeaks had the intention to redact and if needed even via the Pentagon.

> but we couldn’t, so we did the wrong thing instead.

They did no 'wrong' thing instead. They tried to consult the U.S. Government about any needed redactions and then published vital information to inform the public that the government is committing war crimes of foreign soil in their name.

Not publishing that would've been wrong and was most likely the goal of the Pentagon in not cooperating.

Is similar with zero days, researchers publish them if the vendor doesn't cooperate because not doing so and letting black hats exploit a known bug is way more 'wrong' than publishing the 0day widely is.

Except of course she fails to note that Assange tried[1] to do that and was rejected.

She cites the Guardian who has a history of questionable reporting on Assange and WikiLeaks because they didn't do a good job[1][2].

In fact WikiLeaks made a point of going via the newspapers after being blamed.

1 - https://www.salon.com/2010/08/20/wikileaks_5

2 - https://www.bbc.co.uk/news/uk-51633303

Seriously?[1]

https://www.theguardian.com/business/2020/oct/07/covid-19-cr...

> Why would the intelligence community be involved with decision-making inside the department of justice?

Because the intelligence community hates Assange and what he represents. They spied on US lawmakers, tortured, manufactured evidence... I find it hard to believe they WOULDN'T meddle in this case.

> Obama's DoJ apparently decided not to pursue the case, why would we expect Biden's DoJ to come to a different conclusion?

Because post 2016 election the Democrats are no friends of Assange and WiliLeaks, regardless of the implications for press freedom.

Imo the problem is that the ruling accepts the premise that the case has merit i.e. is criminal in the UK, that itself is a threat to press freedom given the charges.

> It seems to me she looked at the appropriate laws and made a reasonable decision.

It is true that the UK technically doesn't guarantee 'freedom of the press' per se, it does have laws however that protect the freedom of expression, not as strongly as the 1st Amendment but still.

Further, there's a long precedent of British newspapers doing what WikiLeaks does and even collaborating with WikiLeaks without being prosecuted.

It's clear Assange is someone who the intelligence community views as an individual who crossed them and needs to be used to deter others. Reading the judgment it is hard not to come to the conclusion she agrees with this view.

Most of the people in the intelligence community and beyond who hate being challenged will stay at their posts way past that date, not that Biden has a different take here.

A caveman may well find that while he was hiding there the outside world no longer dumps in random places.

Yes, the fact that the extradition wasn't rejected on press freedom grounds makes me think maybe it's just a way for the judge to shake it off so that it's not HER who goes down in history books as to have made the decision to extradite.

But having sided with the U.S. on pretty much all of the counts concerning press freedom, an appeals court may well 'find' that the heath condition is not enough.

I REALLY hope am wrong here.

But it goes to show the West is again only concerned with 'press freedom' when it's our strategic competitors violating it.

> Have you ever heard of mdev? As described in "mdev like a boss"? Or its cousin mdevd from https://skarnet.org/software/ ?

I have. I also have heard it runs into trouble with the likes of GNOME/KDE.

Is this seriously your 'competitor'? I did have a good belly laugh at this one, thanks!

> complaining is free

Is it? I know a lot of HN thinks in terms of stocks, options, VC rounds etc. but time and energy is not 'free' either and is exactly what the author had to spend.

> Those that conform will have easy lives, riches, and will coast off the hard works of others.

Agreed. Exactly like Rand and now her institute do[1].

1 - https://reuters.com/article/health-coronavirus-ppp-ayn-rand-...

Were these other systems willing to pick up the slack in maintaining consolekit or coming up with their own solution? Didn't look like it. What about udev? Why did systemd devs have to pick the slack on that too?

Is is perhaps because the other init systems are only willing to touch a very narrow definition of init while depending on rotten, unmaintained pieces of the ecosystem like consolekit without being able/willing to maintain it themselves?

Or perhaps the plan is to let systemd folks do that while shitting on it so we can cook up a 600 LoC 'minimal init' while outsourcing a whole lot to systemd maintainers while taunting our minimalism?

> I've never seen the inconsistencies,

I've seen plenty to convince me that having a full shell scripting language and not a very good one at that as your service definition language is a terrible idea.

> No other service should hide the shortcomings of other services.

I don't think you get it. It is not hiding the shortcomings of other services. It is implementing its own service because the other one was a pile of unmaintained crap. But I guess that kind of security risk is OK as long as it's a separate repo? What a weird dogma.

> That's the point. If that task can be handed over to another daemon (like udev) for setting it up, why systemd assumes that setting it up is its job?

It does hand it over to udev, but someone needs to notify udev stuff is happening. systemd has easy access to that information so it does the job. Also, you do realize that the people who maintain udev are the same who maintain systemd right? Again, because it was a hard job and nobody else, including other init systems, were willing to pick up the slack.

> what I tried to say there. I wanted to say that there's no easy way to see whether a feature is managed by systemd or not

I understand that but imo that should be on the distro to communicate. On Arch for example, the wiki always gives a clear indication of whether a thing like DNS can and is managed by a systemd component or not.

A `systemctl component list --status=enabled` would perhaps be a nice addition, agreed.

> I strongly oppose and criticize is the blind egg-throwing to other init systems, the overzealous protection of systemd and avoiding discussing its potential shortcomings and problems altogether.

It's funny you say that because as a very early adopter of systemd I saw things up close and it was the exact opposite. People were literally threatening Lennart Poettering with violence for writing a (good imo) piece of free software. That he decided to stay on the scene despite that is honestly remarkable.

But as for other init systems, I don't doubt there's some good ones, sysV init wasn't it, but the main problem is that all the others seem only interested in the init part and are happy to depend on rotten parts of the ecosystem. Unlike systemd, none of them were saying; 'ok, consolekit is unmaiintained, let's pick up the slack on session management' (maybe in a separate repo if you insist) or 'oh, udev is struggling, let's pick up the slack' - no they were like am going to do init and hope these other pieces don't come crashing down like a pile of bricks.

Also, I've started using systemd-homed to make my setup portable across my machines. None of the supposed competitors of systemd offer that either.

I like to compare it with PulseAudio; people suggest to me all the time how OSS, ALSA etc. are 'good enough' etc. but I have a fully FLOSS wireless audio house setup right now thanks to PulseAudio, none of the supposed 'competitors' offer that, so they're not competitors for me, (PipeWire eventually might by literally re implementing all of Pulse).

> I want to remind that, parallel sysV-init was pretty fast machinery and was very manageable.

That does nothing for the fact that SysV init was a pile of shell scripts inconsistent across distros and even individual packages. I'd take systemd's declarative, portable service definitions any day over that mess.

SysV init did not take care of consolekit being an unmaintained mess either. systemd did.

Besides, systemd can recognize that I had plugged in a specific kind of device that needs this sort of setup and do that for me automatically. Hence the 'manager' part. None of its supposed 'competitors' can do that themselves.

> Kernel doesn't breach this principle either. It provides an interface between the hardware and software & lives in its own space; that's it.

I don't know, eBPF for example is an entire complex beast of its own that could be argued to violate that, well beyond what's 'required'.

If you take the view that as long as the system has a single defined job, (interfaces to hardware and exposes APIs to userspace for the kernel), systemd does have a definition like that too. It manages the system's dynamic resources during its lifetime. That's a 'single' job. It's not if you decompose it, but the kernel is in a similar situation at that point.

> When systemd overtakes a part of the system with its module, it's very hard to discover it.

systemd does not do that, sounds like you're blaming bad distro defaults (optional components being enabled by default) on systemd.

> My personal opposition about systemd is about binary logs

syslog-ng supports the systemd journal natively so you'd never see a difference from before if you don't want to.

> doing against "doing one thing, well" principle

The principle is dogma that has held back Unix imo. It's useful for simple CLIs but that is about it. By your definition the kernel itself goes against the principle.

systemd is a systems manager, it takes care of it during its entire lifecycle, keeping home directories portable is one thing it can do for you that is entirely optional but very useful, managing containers is another. These are however separate components - homed and systemd-nspawn respectively. It is not all rolled into a single 'systemd', this is a misrepresentation.

systemd is very modular. People like to paint it as a monolith because it lives in a monorepo for the most part, but it is not actually built as one and individual components can be disabled or swapped out.

You need to seriously read more on Rust before making judgments. You're clearly confused.

What '2 is Copy' means precisely that Rust WILL NOT 'introduce pointers where they don't need to be' - 2 is fine to 'alias' because it's a primitive type and so a copy is made when you do that, (i.e. the type implements the 'Copy' trait). However when you do that with complex types that do not implement Copy, you're moving ownership to the new variable so cannot use the old one any more.

> why the heck would you copy pointers?

Pointer aliasing is not always obvious.

> Variables can be varied... you can increment, decrement, do whatever you want with them.

Variables by themselves are not much. They inherit the properties of the type they are bound to. So what you can do with them can be as restrictive or as permissive as the type allows. That type can be a pointer/reference as well.

> ...but it can also have values in it which are not 'static.

I don't think that's right. It can only have references which live at least as long as 'static does (or longer, but 'static is the longest so...)

> T: 'static does not mean the references in T must exist for the lifetime of the application.

It means that T does not have non static references, so it is not a requirement that it lives for the lifetime of the application but can do so.

> Is there somewhere they are saying the name is morally wrong?

Literally that wording? No.

But that's the same as a politician doing favors for their biggest donor and then pretending there's no pay to play here since you didn't literally see him taking piles of banknotes in a smoke filled back room. Come on.

> they made a commercial decision

Yes but why? Because according to them it promotes objectionable items/behavior - that's a moral decision, it is also a commercial one but based on a moral judgment.

A commercial decision is not a class on its own. It is taken based on some factors. What were the factors here if not that Apple finds the name/icon morally questionable?

App developers on what names are 'inappropriate', if you will.

Apple themselves have featured this app[1], which feels like they endorsed it before.

1 - https://apps.apple.com/us/story/id1470456860

> implying Apple is uniquely evil.

It's not that they're uniquely evil, rather that they don't have the moral authority to lecture.

Not because of violence btw.

What systemd gives is structure + consistency; service definitions are declarative and knowledge distro portable.

To me that that is the big benefit of systemd over sysV init.

> Pounds of additional attack surface

Again, show me a major in the wild exploit that abuses these supposed 'pounds of attack surface'. As was said before, systemd doesn't actually have that much new surface that wasn't there before. It's just before it was not maintained in any sort of organized manner but rather was scattered across tens of different projects in various state of no longer being actively maintained, as I said consolekit is a perfect example.

systemd is actually pretty modular. You don't have to run the components that are not useful to you thus limiting the attack surface greatly, if you're actually concerned about it.

I know some people have an allergic reaction to Poettering, but the guy's willing to touch some of the rotten parts of the ecosystems few others dear.

From experience, I highly doubt it was actually unrecoverable. I did something similar many times & all it takes is to read archlinux.org news section & apply .pacnew config diffs where needed. Arch is a bleeding edge distro constantly marching ahead; that's one of its primary advantages, so it's best to update regularly. That being said it is very much possible to not update for months, just requires a bit of extra care when you finally do due to the large number of accumulated changes.

I even did an online, in place switchover from SysV to systemd in 2011 and despite that being a scary amount of changes at once still got a working system.

> Systemd is a security nightmare

I have yet to see solid evidence it is any bigger of a nightmare than a mess of bash scripts that was what came before, but ok.

> taking over various network services ... poorly.

The networking features of systemd are entirely optional. If you don't know how to disable them if you don't want them, the right course of action is not to blame systemd.

People who grew up on SysV init like to shit on systemd as it erases their existing knowledge, but to pretend that SysV init wasn't a total, inconsistent mess or that anyone was maintaining consolekit before logind came around is distorting the truth, to put in mildly.