I can't stop laughing at the irony of this post : https://freenode.net/news/on-free-speech 😂
in fact, all posts from rasengan are laughable. If you want a good weekend laugh, you should subscribe to the #freenode 'news' website.
I rarely read freenode's news because it was only technical updates that wasn't too relevant to me. But now, this person is using an IRC network's news site as their personal ranting space.
oh, and apparently, they have too many designations that they need to use a new one with every new post.
I find myself starting reading on one article and opening so many wikilinks in the process.
#YouTube employs tracking algorithms to "recommend" the next video to watch.
Wikipedia, on the other hand, apparently, have it all figured out to get done organically. Its called #SeeAlso.
I can stay off of YouTube's algorithms, but I cannot on Wikipedia because there is no algorithm to outsmart.
me : *joblessly running `uptime` on a server*
*for no reason* : runs `uptime --pretty`
*thinks to self* : didn't we create that program few years ago that computed a similar output? Wonder if the code is similar...
*brain gets excited about the source code of `uptime`*
goes hunting for the source code of `uptime`... finds it... ( wasn't too hard anyway )
now here I am comparing my code with the source code of `uptime`
what a way to end the day... 🤦 FML!
> My search was starting to feel cursed. Thankfully, I found some older linux-devel mailing list archives, rescued from server backups, often stored as tarballs of digests. I searched over 6,000 digests containing over 98,000 emails, 30,000 of which were from 1993. But it was somehow missing from all of them. It really looked as if the original patch description might be lost forever, and the "why" would remain a mystery.
> Trying to discover, at least, when this change occurred, I searched tarballs on kernel.org and found that it had changed by 0.99.15, and not by 0.99.13 – however, the tarball for 0.99.14 was missing. I found it elsewhere, and confirmed that the change was in Linux 0.99 patchlevel 14, Nov 1993. I was hoping that the release description for 0.99.14 by Linus would explain the change, but that too, was a dead end:
> I dumped "git log -p" for the entire Linux github repository, which was 4 Gbytes of text, and began reading it backwards to see when the code first appeared. This, too, was a dead end. The oldest change in the entire Linux repo dates back to 2005, when Linus imported Linux 2.6.12-rc2, and this change predates that.
I was researching on system load averages and came across this blog post : http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html
I was surprised with the dedication that this person went ( literally ) digging into archives from 24 years to find the source of one particular change - why #linux factors disk usage ( or any TASK_UNINTERRUPTIBLE process ) into the system load equation.
( thread )
@shine yeah, Python doesn't like this style. But it can be made more Pythonic:
- provide an empty list as a default to avoid checking for 'route_table' key
- no need to check for `if rtb['route']`, since an empty list just won't iterate
- do it all as a list comprehension to avoid repeatedly calling .append()
public_route_tables = [
for rtb in resource_by_type.get('route_table', )
for route in rtb['route']
if route['id'] in INTERNET_GATEWAY_IDS
Well, though I didn't want to, I copied the kernel to the systemd-boot end and then everything worked.
But I still don't understand the underlying problem yet. I hope someone can enlighten me.
Does someone know how to fix this from the emergency mode shell?
The problem is that my `/boot/efi` is not being mounted during boot via systemd-boot. But it works if I boot via grub.
The same problem exists the other way around - if I boot into another OS from grub ( but its initramfs was compiled using systemd-boot )
`update-initramfs -u` didn't work.
You cannot boot into an OS ( from systemd-boot ) that did a kernel update when booted via grub and the initramfs was recompiled.
I should have purged grub earlier, but I thought it would be harmless being left alone. :facepalm:
I know of the #GNOME GitLab instance that is at gitlab.gnome.org which is a violation.
Did @gnome obtain any special permissions to use the sub-domain?
I hope that the policy was not overlooked. There should have been some sort of dialogue between the organizations and some arrangement that was reached after deliberation.
Nerd | Tech Freak | Linux Geek | Terminal Freak | Open source lover | Free Software zealot | DevSecOps | Privacy Enthusiast
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!