I'd say there should be a path of not dealing with password rules by getting away from passwords.

I also say that the fact that PKI is considered annoying is a bit of a failure of the industrey to make it easier. Fundamentally, it's not a hard thing, but usability hasn't been high on the list.

Big problem in general is that you have some people on one side trying to get stuff done, but being woefully clueless about security, and then on the other side people who *only* care about security, failing to understand how they could make good security practices more frictionless in the use case. Then you have horrible things where the security people can't *possibly* review the whole body of work and there remain glaring issues while ugly bolt on of 'security' in awkward ways that make way less sense than it *could*.

Well, what do we "know" about security really? Have two "high security" companies point their security auditors at each other and most likely they'll both fail each other, while they would pass themselves. "Security" experts regularly hold contrary views from each other on the "secure" way to do this or that. There's some obviously "bad" security practices, but a lot of disagreement on "good" security practices.

Very unhelpful is the myriad of "security" vendors hawking their wares and many of these arguably decrease security. For example, one of the use cases for SolarWinds that was pushed was that you could see security issues, and at least some companies deployed that solution precisely for the marketed security benefit, but opened themselves wide open because the same access SolarWinds needed to monitor was weaponized to attack the systems. Some have web proxies intended to provide security, but inject untrustworthy certificates to successfully MITM TLS connections in the name of security. Beyond that, you have snake oil, like a myriad of MFA vendors that make a simple technique and make it convoluted and insist, for example, that ssh key based authentication must be disabled for security in favor of their mobile app.

Now I could be surprised, but I wager that Microsoft's discipline would broadly be considered "adequate" when measured against moderately "secure" companies, but they are a huge target. There are likely more hardened, but I'd wager most would be decent.

As far as I know, the software you'd want is 'Audacious', which has a 'Winamp Classic Interface' mode that can load the skins.

Unfortunately, in Winamp classic interface, it's all bitmap based so with high DPI displays it's either tiny or very awkwardly scaled. I'd also love something honoring the "Winamp form factor" but with more modern UI design, maybe with vector instead of bitmap if wanting to do the skins.

I appreciate the "library management" sort of view when actively dealing with the music in interesting ways, but wish more would have a "make a player focused window" for being present, but "ambient".

"Gitlab has yet another severe security vulnerability" is barely "news" at this point, it happens so often.

Gitlab is one of those software that puts a reasably nice looking "box" around dubious chunks of code vaguely duct taped toogether. You can do an easy deployment that nicely seems to work, but if you look a little harder, you can see a bunch of complex hard to debug interactions that you just have to hope never goes wrong.

With predictable implications for security, where vulnerabilities love overly complex interactions where it's likely that no one in the world actually properly understands the overall picture.

So it doesn't work fine.

The reason doesn't matter, what matters is that applications that use DX12 and Vulkan generally can't work in Windows 7 (with some select exceptions). From a technology standpoint, they could have given Windows 7 all the features, but logistically, they didn't.

His comment answered the 'why not port it?' by mentioning Windows 7. Going to Qt6 prevents it from going with Windows 7.

On one hand, I get it, Windows 7 was the last edition before the platform agenda shifted to be all about cloud accounts, telemetry, and being an ad platform. So if you are a Windows die-hard but can't get on board with that BS, then Windows 7 is it.

On the other hand, Windows 7 is being left behind by Microsoft and a bunch of applications. Chrome has left it behind. Firefox has mostly left it behind, and ESR will finally leave it behind by end of this year. Many games left Windows 7 behind (Vulkan and DirectX 12 are generally non-starters in Windows 7). One music player won't balance out the fact you will not be able to run most new games and can't run new versions of browsers.

So ultimately, it's time to leave Windows 7 behind. If you can't get behind the new Windows, then buy a Mac or run Linux. At this point, Wine on Linux might be able to run a broader number of Windows applications than Windows 7, since it does support DirectX 12 and implements other Windows APIs up through Windows 11.

I have some trane zwavw thermostats and a zwave dongle, and it's never given me trouble. I know that the set up, as is, can continue indefinitely.

I think nowadays Zigbee might be a better path, but at the time that was the best path. I do also have wifi devices, but I have to be careful to check if they demand Internet or not (e.g. I've been happy with my OpenGarage, which is wifi based)

Note that if you have a public IPv4 address, you likely don't have use for IPv6rs at all. It's only useful for people hopelessly NATed or firewalled. If you have a routable, reachable address, you don't need ipv6 per se, as every client will be able to reach you. I've never seen a network client that purports "internet access" that can't access an IPv4-only site, including some 'pure ipv6' networks I've been on.

So if Tunnelbroker will work for you, you don't need it for self hosting in the first place.

Think the point is that the pricing isn't really cheaper than the cheapest cloud instances. In fact, you can still find free tiers that are able to serve a lot of self hosting needs. If your needs are light and have nothing to do with your actual house, then the free tier is a much better deal, as your service is likely to be more available than your home innternet connection.

Now once you have need of even a relatively low end desktop grade system, the tunnel becomes *much* cheaper than a cloud instance.

Also wonder how many of the would-be customers think they need it when their ISP does or could provide at least a /64 as part of their existing service. In that scenario, the only thing the service uniquely provides for such a user is an IPv4 reverse proxy, which means you lose control of TLS termination.

So it's going to be a good deal for people with ISPs that won't provide or will filter out external access and also have significant enough needs to push them into pricier instance pricing. It's going to be a bad deal for people with light enough needs to be cheaper to host, or for people that have it naturally with their ISP service.

I've never come across a scenario where my home hosted server was blocked by anything web wise. I don't think blind blacklisting of ip ranges is a significant thing in web client scenarios.

For SMTP, absolutely this is a thing, where SMTP has basically become a relatively small cohort of servers and everyone else is blacklisted by default.

Well, if your 'self hosted' is 'cloud managed', then I could see the complaint. I know a lot of companies are going for that "even on premise is bricked without cloud" business model, and if this is that, then I'd be wary. Especially since I don't think deploying most self-hosted software is actually that hard and don't need a 'cloud seed' to help.

But yes, the tunnel aspect of it seems unavoidable for users without routable addresses. Though at least everyone I know with a vague interest in self hosting at *least* has a /64 natively provided by ISP that is firewalled in a way that can be customized (done on the in-house equipment), so they don't even need a tunnel. Guess there's likely some ancient ISPs that never did the IPv6 thing, but generally ISPs do it because NAT becomes a bigger pain the more traffic tries to traverse it.

It kind of is a different OS, but it's gestating inside of Linux, growing every year, and at some point it will start deprecating Linux out of the nest and eventually we'll all be running SystemD-OS (which used to include Linux, back in the day).

It looks like they are truly describing hosting yourself, with optional ipv6 tunnel provider for those stuck behind NAT. Admittedly more external dependency than is ideal, but unavoidable if the isp grants no sort of external address, or filters traffic to make it infeasible. A tunnel at least means you can be sure the "meat" of the service is under your control at least.

Create a cloud account at your own risk!

When you're subject to usage pricing, you never know what sort of unintended interaction will cause your bill to go nuts.

I would not be surprised if this weren't the only example of somebody not doing anything wrong, and yet incurring huge charges for things they didn't do.

No, I don't think of security as a 'product'. Also you may want to be more specific. The low hanging fruit is the people that put some sort of service on a network with the password 'admin', because it's "trusted". There's no world in which that is a cost saving behavior, it's just supreme laziness. Now if you get into embedded space, particularly with a lot of legacy design components, ok, that 'network' is going to be trusted. I'd eye things *very* skeptically if someone claims it must be a trusted network and at the same time it is an *IP* network. It's not impossible, but it's *highly* likely that the "must be a blindly trusted network" is lack of understanding, or laziness rather than a statement of feasibility or cost.

No, security is not *necessarily* the opposite of usability, the problem is that in a world where "security" guy is over here and the "get stuff done" person is over there, the security guy tends to mandate things without understanding getting stuff done and makes bad recommendations. Further, you have various vendors convincing people their "security" solution improves security, while it merely adds complexity, frustration, and in many times, vulnerability. Ironically enough, a lot of security "solutions" decrease overall security by any reasonable measure (e.g. a web proxy solution that forces a local certificate authority into all browsers to let it man in the middle, a security monitoring system that demands root/admin level access to *everything* and becomes a point of infiltration, etc). If a "security" product doesn't look like a pain in the ass, then unfortunately the business decision callers don't believe it's security.

However, in new deployments and if you demand it of new products, we can have credible security without a huge cost or pain in the ass. The specifics vary situation to situation, but nearly all IP connected strategies I've encountered that previously had "blind trust is just needed" had a credibly secure hardening strategy possible that was also transparent or nearly transparent to operators and users.

Again, some older networks it's not worth the cost to rip and replace, but everyone should be striving for "I don't automatically trust someone just because they could access this specified network" as they integrate new things.