herczegzsolt

You may still wish to not fix it for various reasons.

What I did not have time to write-up is the bootload of vendor-specific bugs, that are also firmware version dependent. Those are often easy-enough to work around once you know them, but very hard to figure out what is going on.

I've encountered: - AppleTV creating incorrect TCP checksums for packets of youtube/netflix apps, when using 464xlat with a custom prefix. Happens on cable, does not happen on wifi. - MikroTik not sending out RAs with 0 lifetime. - Android VoIP not accepting fragmented IPv6 packets when using 464xlat. - LG WebOS TV supporting dhcp option 108 over cable, not supporting over wifi. - Unifi Multicast enhancements filtering out solicited IPv6 RA-s, but letting through unsolicited RA-s.

And there are also vendor specific non-bugs, like to enable xlat, Android wants ipv6-mapped ipv4 on the domain ipv4only.arpa, whereas iOS wants the prefix in the RA.

And don't even get me started on random Matter devices which think that it's fine for them to just start advertising an ipv6 prefix without any configurability.

Around the same timey I had to learn AVR8 family assembly (for ATMega328P) which was a joy in comparison.

I don't think AVR assembly is any better or easier then 16bit Intel, but just the fact that it's a usable and actually triable thing makes a world of difference.

I guess what i'm trying to say is that you shouldn't underestimate the importance of learning something useful instead of something antiquated, even when it is not the simplest thing to do.

In my case, Cloudflare will identify me as BUD even when i'm roaming at a different country.

This behavior is very typical for the EU, because the telco landscape is fairly fragmented, and each company typically have only one, or at most 2 peering locations.

This may be different within the US where the distances are bigger, and latencies matter more, so there is more incentive to peer locally.

I don't know about the UD bit this will not be very accurate within the EU.

As an example: In Hungary, there's pretty much only one peering hub (bix) and there's only one Cloudflare datacenter. You've already geolocated me better than this hack just by knowing my language or phone prefix.

It probably has not-healthy side effects so I'd not recommend this day-to-day for anyone, try to avoid this myself as well.

For the newletter, i have no idea. Mass-email is hard to get right.

Any out-of-band communication should work which checks for the legal entity, not just something that eventually relies on DNS.

Alternatively, you can always just not let them access the old user, and create a new one instead.

It indicates a deeper cultural issue of "convenience/profit over security" if those are sufficient reasons to not check the sub parameter.

In most EU states you pay taxes to provide medical care to employees. If an employee gets sick or otherwise unable to work, you are usually required to continue paying those taxes even if the employee does zero workhours.

The key part to help small businesses is to mitigate their risk of dispropotional cost. Does not matter if it's a tax or any other payable.

The purpose of the switch is also unconfirmed by the article, but this exact combination of cheap chinese button + ibutton reader were an extremly common retrofit into Opels in Hungary.

The switch basically does nothing, but tha state of it is logged in the tracking system along with the routes the car takes. In many EU countries you tax differently for personal use, so the switch is sort of important for tax reasons.

When there's a daemon running in the background, the attack surface is more commonly understood. The environment is not under attacker control.

Libraries rarely treat data from socket as "trusted" but often blindly trust environment variables, or stdin/stdout/stderr.

> Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team are overly cautious and assign CVE numbers to any bugfix that they identify.

What you describe is pretty much what has happened and still is happening in Hungary.

The conclusion here is that even if the majority agrees that these rules are against the spirit of the democracy, there's nothing practical to do against them. So yeah, checks and balances are important to have in practice, not just in spirit.

When you're relying on self-imposed limitations, radicals will sooner or later take over and do whatever necessary to stay in power.

It was quick enough to convert full-page pdf documents to black and white thermal printers (with scaling, didthering, autocrop and all that) in real time during an http request. Somewhar suprisingly, we also haven't had any memory leak issues, despite simply calling it dirctly in long-lived server processes.

Not sure about the state of the library now - my project has been discontinued - but would definitely check out libvips again if i'd have a need for an image manipulation library.

Many systems - ex: rate limits, malware domain lists - would be very easily and cheaply gambled if domain owners could "disown" subdomains at-will, just with a change in DNS. There's a fairly long review process to get onto the public suffix list for exactly this reason.

There's also the historical aspect, that DNS is a much older technology than the need for the public suffix list. Mozilla at the time couldn't expect that all registries would adopt a new standard quickly or at all. Since there was a need for this information for browser security improvements, the list was born, and gradually become the de-facto standard source of such information.

Knowing many sortware developers, a suprisingly large percentage of them still think about security as annoyance. This is especially problematic, as they tend to have a larger attack surface.

Having access to critical resources and also executing a wide range of semi-random tools and code on your machine is ... less then optimal.

With the rise or supply chain attacks, I believe this is a critical and required change.

You could argue that GitHub should not be forcing that decision on users, but if they want to protect their brand, they kind of have to.

Let's say rent is mortgage + 30%. If we assume all the risks and costs (maintenance, insurance, etc) are eating up all of that 30%, they still make a whopping 200%+ profit in the long run.

In a fair business relation with 20-30% profit, the landlord would actually loose cash each month until the mortgage is over, with the expectation to realize profit when the property is sold. This rarely happens.

What I absolutely fail to understand though is why they don't have long-term focus on diversifying income? All their alternative revenue sources are neglibile, and their strange attempts to provide paid products seem to be either hobby-projects of someone at mozilla (ex: pocket) or a cheap rebrand of a product (ex: vpn).

Am I wrong to expect more from such a technologically capable organisation?

I hope you get to profitability and will be able to offer something more affordable for me (and my team).

I assume that nobody would use installers from an unknown source. What benefit do you see in creating a custom iso over just customzinig after install (possibly scripted)?

With GitHub actions, you have to trust the platform or migrate away, there are no other options.

With many more open alternatives, you have the ability to control these. factors if you need or want to. Most likely you wont.

$5 buys you a decent mobile subscription in Hungary (for this use-case). Setting up Automate is just graph editing. It is not much easier to add apps to Slack itself.

Wish you the best of luck with the service though, there may be a need for this by non-technical people or in other regions.

It is also unsupported - and exceptionally hard - to execute runners without GitHub being available, or to migrate off of the proprietary action descriptor format.

Running GitHub enterprise locally may releive some of these issues, but using GitHub.com with GitHub actions is somewhat of a security and reliability nightmare, unless you trust Microsoft's GutHub with infinite visdom and 100% uptime.

We're concerned more and more about GitHubs behavior ever since the Microsoft acqusition. Due to this, we've agreed not to use any proprietary GitHub solution, including codespaces, actions, as well as copilot. It feels like new GitHub features go towards a data-hoarder, vendor lock-in oriented solution.