The API design has nothing to do with security. The Posix API is completely secure. MS has been able to bolt on exactly this kind of security to Win32.
Win32 has managed to do this without any API change, all the existing APIs work. The same approach would've worked for X11.
What it does is simple - all the functions that deal with windows/handles or events simply do not work on ones that you don't have access to, for example, the EnumWindows function allows you to wall through the tree of windows simply do not see the ones the process has no access to. SetWindowsHookEx which allows you to intercept and modify messages meant for other windows simply doesnt fire for messages you're not supposed to access.
Granted, outside of UWP apps, the application of security is rather lax (this is for legacy purposes, the security's there, just not enforced), but for apps running as admin, or UWP apps, the sandboxing is rather solid.
Moreover, it is possible to choose as the default policy that no program may access a window that it did not open, but then there must exist a very simple method for the user to specify when access is permitted, e.g. by clicking a set of windows to grant access to them.
I would at least like to understand the idea of 'pureness' this API tries to aspire to.
It's definitely not Unix-like, since file handles and writes and epoll, and mmap for IPC are nowhere to be found. Instead you have 'objects' with these lifecycle methods that create/release resources (probably committing the design sin of having these for things which should be pure data, like descriptors).
What's with these XML headers? It's UNIX standard stuff, to have a C API for your code, that declares an API for a library, and then a makefile can just consume it. There's a standard way of supplying, finding and consuming them. Even binding generators are probably more comfortable with C headers, than this XML thing
And what's with the callbacks for everything, like screen resolution queries? In Win32, you can do it with a single synchronous API call that returns a struct that has all the info. It's not like you have to touch the disk or network to get this. In cases where you do, you usually have a call that dispatches a message to another window (which you can also dispatch yourself), and you have to listen to the response.
I did some X11 programming as part of work, and its entirely reasonable and conventional compared to this, much more like Win32 (even maybe a bit more pleasant, but I'm no expert on it).
The API sounds awful (and I've had ChatGPT generate me some example programs, and it's somehow even worse than the author describes), and not only that, the requirement of 'everything be an object', with chains and trees of objects being created introduces a huge source of bugs and bookeeping performance overhead on the application side.
Yes, you do have to do something like this with some things under Windows, but the reason for this is that these objects have duplicates in the Windows kernel.
But here it looks like this is just to satisfy the sensibilities of the designer.
Honestly this sounds like the most epic case of NIH syndrome. Like these guys wanted to write their own OS and userland and break with existing conventions.
That’s an interesting idea. I think the fiber optics for drones works because it is only used once over a short period of time. It seems like a cable connected to a mine could be easily disrupted by dragging an anchor with a small robot boat.
And as another commenter noted, mines get moved by currents, so the cable could get tangled and snap.
In the modern era, the difference between sea mine and drone or torpedo can be a lot fuzzier than you may expect. People think of spikey balls, but some sea mines today can do stuff like use passive sonar to match targets against an internal database before firing a homing torpedo. I doubt Iran has these, but they certainly have the proficiency to think creatively about the problem.
I mean you could have some slack in the cable easily, and have the mine become intert should its cable snap.
You have to be mindful of enemy tampering, but overal I would say the idea's worth investigating.
On an unrelated note, I was also thinking of using fiber optic drones to rapidly set up an unjammable communications network on the battlefield. Surely that would be useful for something?
The fundamental problem of high-wattage charges (say 500kW), isn't to deliver power from the charger to the car, but that there needs to be crazy amounts of grid capacity to support them.
A house has like 10kW peak sustained power consumption (an apt even less), which it rarely reaches, so a park of these fast chargers need the same infrastructure as a small town.
These loads are so huge
Cities like Beijing have strong industry and in general have the infrastructure to it, so it's relatively straightforward to install chargers like these. If you go out into the countryside, this infrastructure disappears, and won't see these fast chargers.
Most European cities barely have enough capacity to cover urban expansion, never mind to support this.
These articles suggest, its just a matter of putting down these stations, and that would solve the charger problem, but in truth, there's often a prerequisite of huge grid upgrades somebody has to build and pay for, which come with the unpleasant sight of these high voltage lines intruding into neighborhoods.
I wished articles lambasting the lack of fast chargers also mentioned this as well.
Sorry, but I think you're wrong on your concern: in China they specifically fix this issue with buffer batteries. From grid perspective, charging is no different than with regular, slow charging stations. You can still limit their capacity (as in cars that can be charged per 24h), the difference here is you can charge quickly.
This is a good compromise for the time being while the grid catches up with demand.
Batteries only help with peak loads, they also cost money and wear out. Let's do some math - a 10 car 500kW charger, with a ~30% occupancy, would draw a constant 1500kW from the grid, if we calculate 3kW average for a household(which is high), that would be the equivalent of 500 households.
In the Netherlands the energy network is undergoing a huge upgrade because of wind and solar- technologies nobody predicted in the 1970s.
Things used to be simple: big power station makes energy and lines transport it to every home.
Now you have vast wind farms far out on the North Sea and millions of buildings have solar panels.
And to top it all off electricity replaces gas for heating and cooking.
At least they're upgrading your network, over here in Australia they've realized (about 20 years after we became one of the biggest users of household solar) that too many people having solar makes the grid unstable and the load unreliable, so they want to start charging solar owners for feeding into the grid instead.
Imo one of the biggest wins of renewables + battery is you can skip most of that infrastructure - you can have solar panels on your roof, on the edge of town, and you can skip most of expensive transmission infrastructure.
As an certified electrical engineer, this is certainly a problem. The main issue is of course how much copper is burried underground and how big transformer capacity is.
The first solution is of course to try avoiding farst charging if possible by charging at home or at work over hours if possible. A faster charge will have to be a more expensive charge. Another solution that could ease things a little is to spread the load on the grid over time by drawing it from some local source (e.g. battery)
Imagine a gas station has a beefy energy storage from which it draws the current in short blasts while the battery itself draws it much more spread out over hours.
This is essentially how it is done in much smaller scales (in terms of time, energy and actual physical size) on printed circuit boards using capacitors. If you'd draw the current all the way back from the power supply any bursty load would affect the voltage on the power supply and thus show up in other psrts of the circuit.
But in the end more electrical energy demand by mobility will lead to more electrical demand, period. And as you rightly pointed out that means more infrastructure, more copper in the ground, bigger transformers, more powerplants.
Ah thanks for the expert opinion. I used to be an EE, but I've not been working in the field for a long time
Forgive me, but afaik you can't really run truly high voltage AC lines underground - the main issues are electrical arcing and capacitive ground coupling, which leads to losses. HVDC has its own issues as well, mostly having to do with electrolysis, and it being crazy dangerous.
I mean, you can, but it's going to be very expensive.
By the way, have there been studies of what a 100% EV society's infrastructure look like, especially in countries without access to cheap and abundant renewables? I feel it's going to be quite a challenge, and would only make sense economically as part of a broader reindustrialization effor (which for the record, I support).
As for batteries, I think solar/wind require those anyway, and if a solar farm is backed by a huge battery bank, those can probably supply these ludicrous kWs these chargers would need, but transmission is going to be a challenge.
I would love to read something that would go in depth on how we would support a renewable based grid that also supports powerful fast chargers, as this I feel this needs to be a part of a society-level project, and I'm growing tired of these 'China's building better electric chargers!!!'-style alarmist articles.
Yeah but I am not talking about high voltage AC under the ground, the bigger problem IMO is literally the last few kilometers to peoples houses. Everything before that costs money as well, but is usually better upgradable by design (at least over here in Europe).
Compliance is crazy sucky - I remember there being a case when one of our vendors was harvesting data like crazy, and we went after them. It was grossly in violation of GDPR, like as bad as it could get.
When we reached out to them, they showed us a cert about how they were GDPR compliant, issued by a huge brand-name consulting firm.
In the paper they said they implemented certain standard-mandated cryptographic measures to 'anonymize' the data. Thing is, they implemented them wrong on purpose, so that they could actually identify users by inverting hashes with a rainbow table.
There was a lot of BS legal reasoning in there but the bigname firm signed off on it. Oh and at the bottom, it had a provision, that if the company were to be sued for breach of GDPR, the consluting firm would not be liable any way.
But this was good enough for tons of companies and govt agencies to just use that software.
At least in cybersecurity, there are no certifications that "certify" that you are secure. There are plenty of them that will assess your processes, their execution, etc., but the reality of the risk is next door. This is typically the case for ISO 27001, which has ISO 27002 (the ex British Standard from the 90s) that theoretically governs the controls you should have in place. But it simply does not work.
When you have a major leak, this is usually a company with half a page of certifications, but, hey, mistakes happen. The key problem that these mistakes come from is a fundamentally wrong approach to cybersecurity, but nobody cares.
If somebody writes something in Rust but doesn't announce the fact, what happens? This is an open question as so far we have no examples of that happening.
Rust is the crossfit of programming languages. Everybody around you needs to know at all times.
On a serious note, nice job OP. This game kind of feels like an ASCII version of Terraria. Might I recommend extended ASCII or unicode for the player though? Right now they look a bit like a lollipop.
If somebody announces that their project is written in Rust but nobody complains, what happens?
Writing any non-trivial video game with Rust is (arguably) interesting in itself since developer velocity in gamedev is generally considered paramount, and Rust has a reputation (rightly or wrongly) for hindering velocity.
So yes, the fact that this is written in Rust is actually relevant and valuable. As opposed to your hollow snark.
Now, OP: tell us more about how that's played out for you.
I dont think the parent comment was complaining, just pointing out the "written in rust" meme. Being the top comment, seems like plenty of people enjoyed it!
Based on the evidence presented by the Hacker News front page, the hype is boundless. Rust is the ur-language that we never realized until... idk, three years ago?
It's a PR ploy. It sounds better than X done in C, mainly because the X has been done countless times in C by now, while "Hello World, but in Rust" still felt sexy three years ago.
Not really, and I kinda envy you that you haven't really worked up close with compliance-related people.
A lot of compliance is basically corruption - while in country A, you might fall out of a window if you don't buy from the right people at 10x prices, but in 'civilized' country B, you have to buy from vendor X (who has the necessary paperwork), at 10x prices, or you wont be able to sell the product - and there are a million ways that they can turn the levers to kick you out of their markets, or at least make you pay protection money to these compliance organizations.
The systems of grift are very sophisticated, and very obvious to anyone but the people perpetuating and participating in them. As they say,iyt is difficult to get a man to understand something, when his salary depends upon his not understanding it.
A lot of compliance software is griftware - Sonarqube is a prime example - most engineers don't think it adds value, and the 'analysis' it produces is incredibly shoddy, but like a lot of cybersecurity products, it relies on a authoritarian company culture, certification TP conditional on using the software and achieving a good score etc and alarmist language with nice dashboards. A classic example, is it tags public fields in Java as a security issue. And then the management see that you are writing 'insecure code'.
And literal mouthbreathing idiots in upper management eat this shit up, or use it as a punitive measure against the devs who by their very nature do all the meaningful work.
I'm not saying all compliance is worthless, but if you approach quality from first principles, a 'compliant' product usually has to clear a very low bar of quality. And compliance usually keeps the quality low, and prices high, by forcing potential competitors out of the market.
And compliance can keep quality low in other ways, I've seen firsthand - by making devs work on BS tasks, or preventing improvements and fixes to codebases, because they're not tracked appropriately by whatever change management system.
I was incredibly wary of doing hacky solutions in these places, not out of a sense of commitment to quality, but the fact that once management sees your hacks WORK (kinda), all requests to clean up the garbage will be stonewalled.
Thankfully LLMs make this busywork very easy, through making this papermill garbage, and nitpicking busywork very easy, which I feel will bring at least some positive change in the world (at least to those who do meaningful work)
Sonarqube did not flag public fields as a security issue by default the last time I used it — however it has found several real vulnerabilities for me before.
It did by default for me, and there are a bunch of other poorly implemented analyses, such as it incorrectly flagging Dictionary keys in C# as mutable, or opinionated stuff like it disliking certain names and patterns, forcing me to make arbitrary changes that often cost performance, readability or API cleanliness.
Or insane stuff like it doing a blanket-ban on security related code in the app (but importing a third party lib that does the same is fine).
The analyses in general are low quality and you can see not a lot of effort or thought went into them.
They are not the product - compliance, and dashboards for boomers is.
I'm curious about what did it detect for you? In my experience it stops very obvious bad patterns like using string manipulation to submit SQL (which in certain circumstances might even be fine, even necessary), but it can't really trace non-obvious security issues (like tracing a value through the code, making sure its valid on every codepath), it just doesn't have the compiler machinery to do that.
Of course it's possible to find a giant ship. The interesting parts are that this vector is crazy cheap using public APIs, and the irony of the location source being the voluntary-or-ignorant active telemetry from a US service person.
It's possible to go to the moon, launch ICBMs, and make fusion bombs. It's news when something possible gets cheap and easy. It's also newsworthy when one of the most powerful and expensive weapon platforms in history doesn't have its infosec buttoned down.
Interesting point. On one hand they probably don't care if everyone knows where the carrier is (actually I'm pretty sure every military power knows where the other powers' military is), on the other hand from a "good practices" perspective, it doesn't look good.
Would it just be virtue signaling, or is there more to it?
>It's also newsworthy when one of the most powerful and expensive weapon platforms in history doesn't have its infosec buttoned down.
Well, peace makes you sloppy. No one is at war with France right now, and no one is realistically going to attack this ship.
If we were fighting WW3, you can bet sailors wouldn't be allowed to carry personal cellphones at all. Back in WW2, even soldier's letters back home had to be approved by the censors.
reply