I think it is not an exaggeration to say that without Wireshark, so much of modern computing would never have been developed and we would be stuck in the past. The amount of visibility it gives is immense. I have used it for years, decades now.
Half the time I read the stories they're just a thinly disguised ad for some flavor the day SaaS, so at least in this instance the hook was somewhat useful. Now if everyone uses this to shill their SaaS, then maybe not.
People are getting fired and are having to rely on gig work to live. It's a reporting gimmick by both administrations to convince us the economy is doing better when it hasn't.
Wow I never knew I "can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem".
Plain-text folder on a cloud sharing service. Edit with notepad.exe or whatever editor you prefer. Others have been doing it with .doc files forever, or .rtf.
It may not be illegal for someone to have close ties with the Chinese, but we should also not let them control one of the most important companies for the US military and industrial advantage over our rivals.
America is supposed to be a nation of laws, not a nation of political purges. If we start punishing people based on vague suspicions or geopolitical anxieties rather than actual legal violations, we’re not defending democracy - we’re imitating the very authoritarian regimes we claim to oppose.
Intel’s CEO isn’t accused of espionage or sabotage. The Justice Department accepted a plea bargain. Case closed. If that’s not good enough for you, maybe your problem isn’t with Intel, it’s with the Constitution.
We don’t preserve our military and industrial advantage by abandoning due process. We preserve it by investing in strategic capabilities - like Intel’s foundry expansion - and by upholding the rule of law even when it’s inconvenient.
If you want to beat authoritarianism, don’t become it.
Alloca is a fundmentally insecure way of doing allocations. Languages that promote alloca will find themselves stuck in a morass of security messes and buffer overflows. If Zig were to adopt alloca, it would make the catastrophic mistake that plagued C for over several decades and introduce permanently unfixable security issues for another generation of programming languages.
alloca is a significantly better and safer allocation strategy than the thing it supersedes (fixed size buffers). It's not great but it's definitely better.
I’ve been defending alloca() here, but no, strdupa() (not to be confused with shlwapi!StrDupA on Windows) is a bad idea. In cases that I think are acceptable, the size of the allocation is reasonably small and does not come from outside the program. Here you’re duplicating a string that you probably got somewhere else and don’t really control. That means you don’t really know if and when you’re going to overflow the stack, which is not a good position to be in.
(Once upon a time, MSLU, a Microsoft-provided Unicode compatibility layer for Windows 9x, used stack-allocated buffers to convert strings from WTF-16 to the current 8-bit encoding. That was also a bad idea.)
I used to work at a game company fresh out of college, and this is simply untrue. The company made roughly 40% of sales from cheater whales (one can imagine how much the chest makers made), and there were guidelines on repeated bans where we recognized similarities to make sure we wouldn't ban them again too early.
I left the industry because of thah and the other things like loot boxes and matchmaking for profit and to push micro transactions. It's a terrible place.
I guess you worked somewhere where that was considered a good business strategy then. I worked at a large publisher for over 10 years on couple big competitive titles and the idea always was to get cheaters off our service asap and permanently, no matter their spend(in fact we couldn't see that and it never made any impact on our engineering decisions around the problem).
>>It's a terrible place.
Some companies sure.
And yes sorry I realize I said "no one does this" - let me correct myself to say that in my experience at a couple big publishers this isn't a strategy anyone pursues because it's not worth the losses to your legit playerbase and reputation. But there might be companies that do this, I concede.
The rules of traditional warfare will still exist, they will just be fought by advanced hyper intelligent AIs instead of humans. Hunter Miller humanoids like Optimus and drones like Anduril will replace humans in war.
War will be the same, but the rich are preparing to unleash a "new arsenal of democracy" against us in an AI takeover. We must be prepared.
> Hunter Miller humanoids like Optimus and drones like Anduril will replace humans in war.
You do not understand how war is fought if you sincerely believe this. Battles aren't won with price tags and marketing videos, they're won with strategic planning and tactical effect. The reason why the US is such a powerful military is not because we field so much materiel, but because each materiel is so effective. Many standoff-range weapons are automated and precise within feet or even inches of the target; failure rates are lower than 98% in most cases. These are weapons that won't get replaced by drones, and it's why Anduril also produces cruise-missiles and glide bombs in recognition that their drones aren't enough.
Serious analysts aren't taking drones seriously, it's a consensus among everyone that isn't Elon Musk. Drones in Ukraine are used in extreme short-range combat (often less than 5km in range from each other), and often require expending several units before landing a good hit. These are improvised munitions of last resort, not a serious replacement for antitank guided weaponry. It's a fallacy on the level of comparing an IED to a shaped-charge landmine.
> but the rich are preparing to unleash a "new arsenal of democracy" against us in an AI takeover
The rich have already taken over with the IMF. You don't need AI to rule the world if you can get them addicted to a dollar standard and then make them indebted to your infinite private capital. China does it, Russia does it... the playbook hasn't changed. Even if you make a super-AI as powerful as a nuke, you suffer from the same problem that capitalism is a more devastating weapon.
>These are weapons that won't get replaced by drones
Those weapons are drones. They're just rockets instead of quadcopters. They're also several orders of magnitude more expensive, but they really could get driven by the same off-the-shelf kind of technology if someone bothered to make it.
And they will get replaced. Location based targeting is in many cases less interesting than targeting something which can move and could be recognized by the weapon in flight. Load up a profile of a tank, a license place, images of a person, etc. to be recognized and targeted independently in flight.
>Battles aren't won with price tags and marketing videos, they're won with strategic planning and tactical effect.
Big wars tend to get won by resources more than tactics. Japan and Germany couldn't keep up with US industrial output. Germany couldn't keep up with USSR manpower.
Replacing soldiers with drones means it's more of a contest of output than strategy.
I am not talking about drones like DJI quadcopters with grenades duct taped to them or even large fixed wing aircraft, I am talking about small personal humanoid drones.
Civilization is going through a birth rate collapse. The labor shortage will become more endemic in the coming years, first in lower skill and wage jobs, and then everywhere else.
Humanoid robots change the economics of war. No longer does the military or the police need humans. Morale will no longer be an issue. The infantry will become materiel.
XDG_BIN_HOME is crucial, without it, not supporting the spec seems like the right call. Better to deal with the status quo until updates happen than to get stuck in bikeshed hell.
You're letting perfect be the enemy of good. Other projects, like python, use $HOME/.local/bin as the spec suggests and it works out fine in virtually all cases.
> "User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place."
> "Since $HOME might be shared between systems of different achitectures, installing compiled binaries to $HOME/.local/bin could cause problems when used on systems of differing architectures. This is often not a problem, but the fact that $HOME becomes partially achitecture-specific if compiled binaries are placed in it should be kept in mind."
The omission of XDG_BIN_HOME is regrettable, but not a showstopping problem unless you want it to be a problem. W.r.t. a single $HOME across multiple architectures, "not often" a problem is an overstatement of the problem; the number of people using a single $HOME across multiple architectures is a rounding error (I say that as somebody who once did so) and such people are already accustomed to dealing with the difficulties that arise from it. They're going to hoist themselves with Go and Rust's defaults anyway.
