The US did not "pick up" Europe's defense bill out of charity. It ran a garrison empire because forward bases served American interests: containing Russia, projecting power, locking allies into US weapons. European welfare states are funded by European taxes, not Pentagon largesse. Defense is nowhere the "largest expense" of any developed country, pensions and healthcare are. Europe rearming is overdue, but the right framing is strategic autonomy from an unreliable partner, not a wayward teenager finally paying rent.
> the right framing is strategic autonomy from an unreliable partner
Yes but that's an uncomfortable framing for online-americans to use when they want some gotcha argument
And not a useful one for US administrations in the last 30 years (trump was far from the first one) to make because the (mostly) unstated assumption was that the vast majority of increased spending would go to american manufacturers to prop up american jobs
I built Collider, A wrap-based package and dependency manager for Meson.
I needed a way to use and push my own artifacts in Meson projects. WrapDB is fine for upstream deps, but I wanted to publish my packages and depend on them with proper versioning and a lockfile, without hand-editing wrap files.
Collider builds on Meson’s wrap system: you declare deps in collider.json, run collider lock for reproducible installs, and push your projects as wraps to a local or HTTP repo. It’s compatible with WrapDB, so existing workflows still work: you just get a clear way to use and push your own stuff. Apache-2.0.
so you can upload (er, provide access to) an image of a PCB you are looking to trace
Edit: I should have used a different word than upload. It's just old habit. According to TFA, there is no uploading. All processing is done in the browser, so the app needs local file system access to get at your image
There are other ways for webpages to get file uploads than this particular JS API. I upload files via firefox every single business day as part of my job.
This JS feature doesn't upload the file to a server. This particular app says right there on the page that it does the magic in the browser.
You appear to be misunderstanding on how browsers handle file uploads. You cannot get the local file path for a file. There is no C:\ or /Volumes or whatever your OS uses. Browsers deliberately mask that from the upload.
You can 'upload' a file into a completely local web app just fine. The directory access is only necessary if you need the web app to be able to spontaneously write back to the original file on your machine, or if you want to read a whole directory tree, which might be slightly convenient for things like gerbers but can easily be dealt with in other ways (especially with gerbers, which you can distinguish by filename, something that the web browser does expose to javascript).
(and I do think it's kind of irritating that Mozilla is fighting against such useful features on somewhat patronising 'the users won't understand what permission they're granting' grounds)
To do what with? Upload? That's totally not the same thing as providing access for directly manipulating the file. That's basically HTML1.0 type stuff. JS file system access to provide a file to, I'm assuming, a WASM app is not even the same sport to be in the same ballpark.
Access for directly manipulating the file isn't necessary (perhaps if the files were enormous, but images and Gerber files aren't). One can upload/download files from a local web app just fine on firefox, and the WASM app can act on the file in memory with whatever APIs it wants.
PCB Tracer reads and writes over a dozen different file types — including images, schematics, datasheets, netlists, and revision history. It also provides an AutoSave feature, to prevent losing your work. Every file is saved to your project directory during a session. Doing all of this without constant interruptions to get user permissions requires the File System Access API, which is not yet available in all browsers. The Firefox developers have explicitly stated that this API will not be supported.
The File System Access API has security precautions built-in. For example, it requires users to explicitly grant permission to access a specific directory (once) per session. Also, the API never allows access to root or to system-related directories.
Youtube is far too significant a video collection to risk losing it. Yes there is insane anounts of garbage and yes their history is getting spottier by the day, but nothing else comes close to all of the good stuff that is still on it.
Google needs to get its shit together and give users power tools. YT hasn't improved materially for many years now. I hope they can snap out of whatever governance dysfunction they're in. Not sure whether increasing financial pressure (above what must, no doubt, build up on its own) is the right answer here. It will probably only lead to more enshittification, and a long, slow death and I'm pretty saddened by that thought.
Youtube could vanish from existence tomorrow and I'd probably just be upset that there isn't a place that might show me a 180p 20 year old video of how to properly clean my old dishwasher. I don't really know what these super high value videos are other than those. I really don't know why they must all exist on this one platform either.
>Youtube is far too significant a video collection to risk losing it.
> Not sure whether increasing financial pressure (above what must, no doubt, build up on its own) is the right answer here.
fantastic, an appeal to personal guilt to fund large corporate money making and national/corporate-soft-power efforts.
an acquired predatory advertiser, the worlds #1 inadequate and neglectful child nanny, and world wide cultural trend-setter is also bad at making money? and they need more? and you say they won't squander it?
I think i'll donate to PBS while aiding YT archival efforts.
Maybe try Spectacle. I use the OOTB Spectacle app on Fedora KDE. It has the same features as Flameshot and is .. well, native.
But on my Mac, I use indeed Flameshot, it's not ideal (the window is "shrinking" when a screenshot is captured), but it's better than any alternative I tried.
> Because it's a black box [...]. No source code available?
You know Shottr is only available for macOS, don't you?
If source code is so important, why do you even bother using macOS?
I wouldn't install Shottr on any of my Linux machines, even if available. Despite it being objectively better than any available alternative. I'd recreate one myself if necessary.
But on a corporate Mac, where 99.999% of executed code is a black box, why bother?
Huh? I'm running kde plasma on wayland and flameshot runs like a dream come true. I hit the flameshot icon in the tray, it automatically selects the whole screen to save, or if I click it starts cropping wherever I move the mouse. It's like the devs read my mind for exactly what I wanted
I'm running the same, but for me it's definitely not a smooth experience compared to plasma + X. Indeed I resorted to clicking on tray icon because invocation from custom shortcut doesn't allow me to Ctrl-c (copy to clipboard). On the other hand, clicking from tray breaks Ctrl-s (save to file). Oh, well.
Every Wayland compositor has a different feature set, and KDE is one of the more open to implementing features. It's likely that other people have compositors that stubbornly refuse to implement screenshots for security reasons.
My dad got rid of his C15 after driving 1 million kilometers with it (rural France)
The engine was fine surprisingly, the body was rusted to the bone though
Surprisingly easy. If the language has a lot of conjugations (e.g., polite past verb forms), running each word through Snowball first makes the process a bit easier.
reply