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.
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.
deleted by creator
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.
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).
For example, I might self host a server just for my account but I read all my content from lemmy.world. Am I not using their bandwidth and their resources anyway?
Well, it’d use your CPU to generate the webpages that you view. But, yeah, it’d need to transfer anything that you subscribe to to your system via federation (though the federation stuff may be “lower priority” – I don’t know how lemmy and kbin deal with transferring data to federated servers rather than requests from users directly browsing them at the moment, but at least in theory, serving the user browsing directly has to have a higher priority to be usable).
But what would be more ideal – and people are going to have to find out what the scaling issues are with hard measurements, but this is probably a pretty reasonable guess – is to have a number of instances, with multiple users on each. Then, once lemmy.world transfers a given post or comment once via federation, that other instance stores it and can serve up the webpages and content to all of the users registered on that other instance.
If you spread out the communities, too, then it also spreads out the bandwidth required to propagate each post.
As it stands, at least on kbin (and I assume lemmy), images don’t transfer via federation, though, so they’re an exception – if you’re attaching a bunch of images to your comments, only one instance is serving them. My guess is that that may wind up producing scaling problems too, and I am not at all sure that all lemmy or kbin servers are going to be able to do image-hosting, at least in this fashion.
I can’t speak as to why other people use their alternatives, but if you use mpv with yt-dlp like the guy above, and which I do – which isn’t really a full replacement for YouTube, just for part of it – then you can use stuff like deblocking, interpolating, deinterlacing filters, hardware decoding, etc. Lets me use my own keybindings to move around and such. Seeking happens instantly, without rebuffering time.
Also means that your bandwidth isn’t a constraint on the resolution you use, since you aren’t streaming the content as you watch, though also means that you need to wait for the thing to download until you watch it.
There, one is talking about the difference between streaming and watching a local video, and that mpv is a considerably more-powerful and better-performing video player than YouTube’s client is.
I generally do it when I run into a long video or a series of videos that I know I’m going to want to probably watch.
EDIT: It also looks, from this test video, like YouTube’s web client doesn’t have functioning vsync on my system, so I get tearing, whereas mpv does not have that issue. That being said, I’m using a new video card, and it’s possible that there’s a way to eliminate that in-browser, and it’s possible that someone else’s system may not run into that – I’m not using a compositor, which is somewhat unusual these days.
I’m not familiar with whatever this Sandisk portable thing is, but SanDisk is a drive manufacturer, in which case it may be drive-level.
googles
Sounds like when it’s locked, the drive presents itself as a CD drive containing a Windows executable that unlocks it.
https://www.techrepublic.com/forums/discussions/how-do-i-fully-remove-sandisk-unlocker/
I wouldn’t expect Linux to be able to write to it if that’s it. It won’t even see the actual drive, just the non-writeable CD drive.
Honestly, I’d probably just write off the drive if the data isn’t important. The amount of time that’s required to basically get a used hard drive is probably not going to be worth it.
I remember this story from about twenty years back hitting the news:
https://www.theregister.com/2001/04/12/missing_novell_server_discovered_after/
Missing Novell server discovered after four years
In the kind of tale any aspiring BOFH would be able to dine out on for months, the University of North Carolina has finally located one of its most reliable servers - which nobody had seen for FOUR years.
One of the university’s Novell servers had been doing the business for years and nobody stopped to wonder where it was - until some bright spark realised an audit of the campus network was well overdue.
According to a report by Techweb it was only then that those campus techies realised they couldn’t find the server. Attempts to follow network cabling to find the missing box led to the discovery that maintenance workers had sealed the server behind a wall.
I suspect that it works like the leafnode Usenet server did.
A full Usenet feed is a lot of traffic.
Leafnode would only download or update a newsgroup’s contents when first requested by a client. But once it did so, it would store that data and make it available to other clients. It kept bandwidth requirements reasonable for Usenet servers with a small number of users.
The idea here is presumably aimed at scaling – to basically try to only download what your users want, but once it comes down for one, to let all the others use it. Optimizes for your instance’s bandwidth.
https://en.wikiquote.org/wiki/Donald_Knuth
Beware of bugs in the above code; I have only proved it correct, not tried it.
Donald Knuth’s webpage states the line was used to end a memo entitled Notes on the van Emde Boas construction of priority deques: An instructive use of recursion (1977)
I’m not arguing that Google should have kept them going.
But I think that it might be fair to say that Google did start a number of projects and then cancel them – even if sensibly – and that for people who start to rely on them, that’s frustrating.
In some cases, like with Google Labs stuff, it was very explicit that anything there was experimental and not something that Google was committing to. If one relied on it, well, that’s kind of their fault.