tal

AGI is not a new term. It’s been in use since the 90s and the concept has been around for much longer.

It’s not new today, but it post-dates “AI” and hit the same problem then.

Reddit had the ability to have a per-subreddit wiki. I never dug into it on the moderator side, but it was useful for some things like setting up pages with subreddit rules and the like. I think that moderators had some level of control over it, at least to allow non-moderator edits or not, maybe on a per-page basis.

That could be a useful option for communities; I think that in general, there is more utility for per-community than per-instance wiki spaces, though I know that you admin a server with one major community which you also moderate, so in your case, there may not be much difference.

I don’t know how amenable django-wiki is to partitioning things up like that, though.

EDIT: https://www.reddit.com/wiki/wiki/ has a brief summary.

No, they are not. They can stop working; they just won’t be able to continue their job under more-favorable conditions.

That still is not slavery. The person in question is still not compelled to work.

Yeah, sorry, but no. That’s not slavery. If you’re present in the country illegally and working illegally and could be returned home at any time, you may not be making as much as you would if you were present legally, but you are not compelled to work. You can always terminate working and return to the country where you are legally supposed to be. If you choose to be in Country A illegally and working there rather than in Country B legally and working (for less) there, that is your choice, and you are not being compelled to work.

Slavery entails someone being compelled to work.

I broadly agree that “cloud” has an awful lot of marketing fluff to it, as with many previous buzzwords in information technology.

However, I also think that there was legitimately a shift from a point in time where one got a physical box assigned to them to the point where VPSes started being a thing to something like AWS. A user really did become increasingly-decoupled from the actual physical hardware.

With a physical server, I care about the actual physical aspects of the machine.

With a VPS, I still have “a VPS”. It’s virtualized, yeah, but I don’t normally deal with them dynamically.

With something like AWS, I’m thinking more in terms of spinning up and spinning down instances when needed.

I think that it’s reasonable to want to describe that increasing abstraction in some way.

Is it a fundamental game-changer? In general, I don’t think so. But was there a shift? Yeah, I think so.

And there might legitimately be some companies for which that is a game-changer, where the cost-efficiencies of being able to scale up dynamically to handle peak load on a service are so important that it permits their service to be viable at all.

The kind where America is expected to go solve everyone’s problems

Well, the current government in Mali is the result of a military coup. The previous, elected government was friendly with France, and the new, military coup crowd is friendly with Russia.

Then when the coup guys decided that they didn’t need to hold elections when they said they would, they got condemned by the US.

https://www.france24.com/en/africa/20220112-un-security-council-falls-short-of-imposing-new-sanctions-on-mali-after-elections-delay

Russia, China block UN Security Council from supporting new sanctions on Mali

Russia and China blocked the U.N. Security Council on Tuesday from supporting new sanctions on Mali for its military leaders’ decision to delay next month’s elections until 2026, a blow to the restoration of democracy in the troubled West African nation.

So I vaguely imagine that said government probably isn’t asking the US to become involved, because the US’s position is that they should have held elections.

They aren’t being blocked from speaking.

Nah, because there are definitely projects Google started on there. The one OP mentioned is on there, and I remember Google Zeitgeist from back when.

EDIT: Not saying that this is comprehensive, but only five entries reference being acquired from elsewhere in their description.

looks to see who the people in question are

Autonomous movement against National Guard expansion in so called Michigan, defend the forest and decolonize the land

I mean, running around trying to block military infrastructure while saying that the state doesn’t exist does sort of seem like the sort of thing that might attract attention.

I bet someone has made a list.

googles

Yup.

The first item on the field is a search field. The “all” category has 288 entries.

https://killedbygoogle.com/

Yeah, I ran into this on /r/europe when there were some EU legislation issues. The EFF does have some activity in the EU, but it does have a mostly-US focus, and there isn’t really a direct analog.

It depends on what your interest is.

EDRi (European Digital Rights) in Europe has come up on a couple of advocacy issues I’ve followed. If you’re in Europe, they might be worth a look. They don’t feel quite the same to me, but maybe that’s what you’re looking for.

What’s been your experience with youtube recommendations?

I’ve never had a YouTube account, so YouTube doesn’t have any persistent data on me as an individual to do recommendations unless it can infer who I am from other data.

They seem to do a decent job of recommending the next video in a series done in a playlist by an author, which is really the only utility I get out of suggestions that YouTube gives me (outside of search results, which I suppose are themselves a form of recommendation). I’d think that YouTube could do better by just providing an easy way to get from the video to such a list, but…

and I wondered if it wouldn’t be a good ides to somehow gather a list of small instances

https://lemmy.fediverse.observer/list

https://kbin.fediverse.observer/list

If you require open signups and then sort by number of users, ascending, that’s an auto-generated list of small instances that (presumably) are looking for users.

Damn. I was chuckling at the image and now I feel kind of bad.

[continued from parent]

https://en.wikipedia.org/wiki/Self-propelled_anti-aircraft_weapon

The introduction of jet engines and the subsequent rough doubling of aircraft speeds greatly reduced the effectiveness of the SPAAG against attack aircraft.[dubious – discuss] A typical SPAAG round might have a muzzle velocity on the order of 1,000 metres per second (3,300 ft/s) and might take as long as two to three seconds to reach a target at its maximum range. An aircraft flying at 1,000 kilometres per hour (620 mph) is moving at a rate of about 280 metres per second (920 ft/s). This means the aircraft will have moved hundreds of meters during the flight time of the shells, greatly complicating the aiming problem to the point where close passes were essentially impossible to aim using manual gunsights. This speed also allowed the aircraft to rapidly fly out of range of the guns; even if the aircraft passes directly over the SPAAG, it would be within its firing radius for under 30 seconds.

SPAAG development continued through the early 1950s with ever-larger guns, improving the range and allowing the engagement to take place at longer distances where the crossing angle was smaller and aiming was easier. Examples including the 40 mm U.S. M42 Duster and the 57 mm Soviet ZSU-57-2. However, both were essentially obsolete before they entered service, and found employment solely in the ground-support role. The M42 was introduced to the Vietnam War to counter an expected North Vietnamese air offensive, but when this failed to materialize it was used as an effective direct-fire weapon. The ZSU-57 found similar use in the Yugoslav Wars, where its high-angle fire was useful in the mountainous terrain.

By the late 1950s, the US Army had given up on the SPAAG concept, considering all gun-based weapons to be useless against modern aircraft. This belief was generally held by many forces, and the anti-aircraft role turned almost exclusively to missile systems. The Soviet Union remained an outlier, beginning the development of a new SPAAG in 1957, which emerged as the ZSU-23-4 in 1965. This system included search-and-track radars, fire control, and automatic gun-laying, greatly increasing its effectiveness against modern targets. The ZSU-23 proved very effective when used in concert with SAMs; the presence of SAMs forced aircraft to fly low to avoid their radars, placing them within range of the ZSUs.

The success of the ZSU-23 led to a resurgence of SPAAG development. This was also prompted by the introduction of attack helicopters in the 1970s, which could hide behind terrain and then “pop up” for an attack lasting only a few tens of seconds; missiles were ineffective at low altitudes, while the helicopters would often be within range of the guns for a rapid counterattack. Notable among these later systems is the German Gepard, the first western SPAAG to offer performance equal to or better than the ZSU. This system was widely copied in various NATO forces.

SPAAG development continues, with many modern examples often combining both guns and short-range missiles. Examples include the Soviet/Russian Tunguska-M1, which supplanted the ZSU-23 in service, the newer versions of the Gepard, the Chinese Type 95 SPAAA, and the British Marksman turret, which can be used on a wide variety of platforms. Some forces, like the US Army and USMC have mostly forgone self-propelled guns in favor of systems with short-range infrared-guided surface-to-air missiles in the AN/TWQ-1 Avenger and M6 Linebacker, which do not require radar to be accurate and are generally more reliable and cost-effective to field, though their ability to provide ground support is more limited. The U.S. Army did use the M163 VADS and developed the prototype design of the M247 Sergeant York.

Russia has been using this approach for a while with the cheap Iranian Shahed-136 loitering munitions.

The problem is that self-propelled antiaircraft guns, SPAAGs are a cheap way to take down relatively low and slow weapons like this.

In the US, we mostly shifted away from SPAAGs to surface-to-air missiles when aircraft shifted to jets; SPAAGs were fairly obsolete against them. By this point, our SPAAGs have all been out of service – and not just out of service, but dismantled and sold off for parts – for decades, and the fact that Germany was somewhat slow to abandon them made their Gepard SPAAGs
useful in Ukraine against Shahed-136s.

https://en.wikipedia.org/wiki/M163_VADS

The M163 Vulcan Air Defense System (VADS) is a self-propelled anti-aircraft gun (SPAAG) that was used by the United States Army.

With the wider use of non-jet-based low-and-slow cheap unmanned weapons, the SPAAG is better-suited as a counter to those.

However, the Soviet Union was slower to abandon SPAAGs, and Russia tends to warehouse a lot of older weapons, moreso than we do. They are probably better positioned to counter such weapons then we are to provide Ukraine with air defenses against them. We’ve mostly been relying on sending elderly Hawk SAMs, which are obsolete against current aircraft but work against Shahed-136s and are numerous enough that they’ll last for a while.

[continued in child]

Yeah, I don’t think I really agree with the author as to the difficulty with dig. Maybe it could be better, but as protocols and tools go, I’d say that dig and DNS is an example where a tool does a pretty good job of coverage. Maybe not DNSSEC, dunno about how dig does there, and knowing to use +norecurse is maybe not immediately obvious, but I can list a lot of network protocols for which I wish that there were the equivalent to dig.

However, a lot of what of what the author seems to be complaining about is not really stuff at the network level, but the stuff happening on the host level. And it is true that there are a lot of parts in there if one considers name resolution as a whole, not just DNS, and no one tool that can look at the whole process.

If I’m doing a resolution with Firefox, I’ve got a browser cache for name resolutions independently of the OS. I may be doing DNS over HTTP, and that may always happen or be a fallback. I may have a caching nameserver at my OS level. There’s the /etc/hosts file. There’s configuration in /etc/resolv.conf. There’s NIS/yp. Windows has its own name resolution stuff hooked into the Windows domains stuff and several mechanisms to do name resolution, whether via broadcasts without a domain controller or with a DC whether that’s present; Apple has Bonjour and more-generally there’s zeroconf. It’s not immediately clear to someone the order of this or a tool that can monitor the whole process end to end – these are indeed independent systems that kind of grew organically.

Maybe it’d be nice to have an API to let external software initiate name resolutions via the browser and get information about what’s going on, and then have a single “name resolution diagnostic” tool that could span multiple of these name resolution systems, describe what’s happening and help highlight problems. I can say that gethostbyname() could also use a diagnostic call to extract more information about what a resolution attempt attempted to do and why it failed; libc doesn’t expose a lot of useful diagnostic information to the application, though libc does know what it is doing in a resolution attempt.

make dig’s output a little more friendly. If I were better at C programming, I might try to write a dig pull request that adds a +human flag to dig that formats the long form output in a more structured and readable way, maybe something like this:

Okay, fair enough.

One quick note on dig: newer versions of dig do have a +yaml output format which feels a little clearer to me, though it’s too verbose for my taste (a pretty simple DNS response doesn’t fit on my screen)

Man, that is like the opposite approach to what you want. If YAML output is easier to read, that’s incidental; that’s intended to be machine-readable, a stable output format.

Duplicity uses rsync internally for efficient transport. I have used that. I’m presently using rdiff-backup, driven by backupninja out of a cron job, to backup to a local hard drive and which does incremental backups (which would address @Nr97JcmjjiXZud’s concern). That also uses rsync. There’s also rsbackup, which also uses rsync and I have not used.

Two caveats I’d note that may or may not be a concern for one’s specific use case (which apply to rdiff-backup, and I believe both also apply to the other two rsync-based solutions above, though it’s been a while since I’ve looked at them, so don’t quote me on that):

• One property that a backup system can have is to make backups immutable – so that only the backup system has the ability to purge old backups. That could be useful if, for example, the system with the data one is preserving is broken into – you may not want someone compromising the backed up system to be able to wipe the old backups. Rdiff-backup expects to be able to connect to the backup system and write to it. Unless there’s some additional layer of backups that the backup server is doing, that may be a concern for you.

• Rdiff-backup doesn’t do dedup of data. That is, if you have a 1GB file named “A” and one byte in that file changes, it will only send over a small delta and will efficiently store that delta. But if you have another 1GB file named “B” that is identical to “A” in content, rdiff-backup won’t detect that and only use 1GB of storage – it will require 2GB and store the identical files separately. That’s not a huge concern for me, since I’m backing up a one-user system and I don’t have a lot of duplicate data stored, but for someone else’s use case, that may be important. Possibly more-importantly to OP, since this is offsite and bandwidth may be a constraining factor, the 1GB file will be retransferred. I think that this also applies to renames, though I could be wrong there (i.e. you’d get that for free with dedup; I don’t think that it looks at inode numbers or something to specially try to detect renames).