There's actually a couple of reasons for Windows apps to make Linux syscalls. I'm pretty certain this is how VST bridging software works so you can use Windows VSTs in Linux DAWs.
The average user expectation is probably not that any random exe they download from the piratehub or whatever can actually run Linux shellcode on their system.
I think all syscalls should be landlocked by default(It might require a novel kernel-assisted mechanism to keep existing official Wine libraries working, not sure).
Some of these programs with Wine support will have to get grandfathered in, of course, but at least let the user add them to a white list with a confirmation popup.
"This program wants to run Linux h4x0r shellcode. Allow?"
And then of course provide a mechanism so that new Wine-aware applications can interact with Linux features in a safer way.
Wine is not a Sandbox but come on. Everyone has been using it as if it was.
Even Bottles was only a prefix-manager until a couple months ago.
I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
> I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
This is not even remotely sufficient. A malicious application could modify the memory pages of WINE code and execute direct syscalls anyway.
If you want sandboxing, use a Linux sandboxing solution on WINE. It's far too late to try to bolt on sandboxing now.
it would be hard to say whether a given program making a syscall is trying to do a native linux sys call or a "naked" windows syscall (something that some windows programs actually do).
but yeah, somehow intercepting syscalls is a prerequisite for either emulating these naked windows syscalls or notifying the user about the native linux ones.
Well there's a few things that have to go right for that scenario to work. It's not impossible but I'd imagine the number of people that could take advantage of it is small.
If I have a passenger that can use the phone - it will be infinitely easier to have them place an order via app. They can look at the map, set up navigation, read through the menu and handle getting the order in, etc.
The driver needs to know where the restaurant is. A lot of time when I'm getting fast food - I'm on the interstate, I don't really know where I am, I just know I saw a sign saying the next exit has a Taco Bell. If anything asks me to confirm the restaurant location as 123 Main Street or in some city - I have no idea if that's right or not.
Maybe if it integrates with Android Auto and Google Maps so I can place an order and get navigated, that could work.
Another big issue is knowing the menu. I definitely wouldn't want to sit and have a robot read me the whole menu. There are some places where I could order without seeing the menu but - if you don't go very often you probably need to see the menu. And if you're not going very often you probably don't have their app on your phone anyway.
The apps don't take how busy the restaurants are into account. If I get to a place and it's slammed, I'll look around a bit for something else less busy, because I want to get back on the road. So I'm not really all that committed to a particular place anyway.
I also tend to not trust the apps. I can't tell you how many times I've placed an order only to find out they're out of something when I get there. If I order at the speaker I get that feedback immediately and can pick something else (or somewhere else).
Basically you need to have all of the following be true:
* Have nobody else in the car that could operate the phone for you
* Know the restaurant location
* Know the menu
* Have the app
* Ready to commit to any wait
* Trust the app is correct
I think there's a deeply-ingrained sense of being in love with our cars, loving to do things in our cars, etc. We made long commutes via car a thing, and I think a part of that was the drive-through - you could get things quickly on your way to/from work.
There used to be a time where the drive-through was a pretty great deal but - for all the reasons you outlined above it's losing a lot of appeal. I think you pretty much hit the nail on the head - businesses prefer drive-through because it requires less staff, less resources. You also eliminate issues with people loitering in lobbies.
There are places where drive-through/walk-up only may be the only way a restaurant will open due to perceived safety concerns. So that I kind of get but ideally, the municipality would find a way to address the actual safety of the area, or at least the perception. Sometimes areas just look dangerous but are actually fine.
But yeah I think the appeal of drive-through is dying out for a variety of reasons. We no longer see cars as convenient, we desire walkability, we value healthier food over faster food, we'd rather work less and have extra time at home to do things like cook, things like that.
I should point out I'm speaking very broadly, as an American who isn't facing poverty. My view is likely limited and skewed, there are very likely to be scenarios I'm not considering.
A lot of Icecast/Shoutcast streams either lack HTTPS support, or they don't have CORS headers, or not the right CORS headers.
Like a very common issue is - if you don't have an access control allow headers header for icy-metaint - you can't pull out the embedded Shoutcast metadata client-side. You now have to pull now-playing type data via some other method, like polling the Icecast API - which may not be available. A lot of servers don't send any CORS headers, some only send the allow-origin header.
In theory stream producers can use Ogg to encapsulate the stream and use bitstream chaining to have in-band metadata. That limits the codecs to Vorbis/Opus/FLAC, which are all great codecs - bigger issue tends to be how the browser handles chained bitstreams in audio elements. My understanding is - they just don't handle it at all.
So - if the goal is to play the streams in the browser and ensure you have a consistent experience, it makes sense to proxy them all into some common format like HLS and serve it over HTTPS. You can have timed ID3 metadata, and eliminate CORS and mixed-media issues. This does mess with the stream's ability to accurately measure things like, how many people are listening.
So I agree in the sense that, you're always going to rely on something. Even if you're hosting on hardware you own at your house, using your own self-signed SSL certificates, you're still relying on an internet connection from some company.
But, I think using the term "fully-owned" to refer to pushing up to GitHub, then deploying to Cloudflare Pages is definitely not "fully-owned"
What I meant by "fully-owned" is really about owning the content and the workflow: everything lives locally in plain text, versioned in Git, and built with open tools. I can move it to any host without being locked into a platform or losing anything.
You're right that hosting on GitHub and Cloudflare isn't infrastructure ownership. I should’ve been more precise with the wording.
As long as they use their own domain and have that registered with some other registrar they can trivially move the blog to any other hoster, including a random VPS. So while the current setup depends on github and cloudflare they don't hold much power over him.
It's not really fully-owned, but it's owned in the ways that matter most
I think the point is that it's not someone else's blogging service. If CF or GH die, you can port this to some other platform or your own server without losing anything, compared to e.g. blogger.
Chained Ogg FLAC works really well as an intermediary/internal streaming format.
In my case - I have an internet radio station available in a few different codec/bitrate combinations. I generate a chained Ogg FLAC stream so I have in-band metadata with lossless audio.
The stream gets piped into a process that will encode the lossy versions, update metadata the correct way per-stream (like there's HLS with timed ID3, there's Icecast with chained Ogg Opus, Icecast with AAC + Shoutcast-style metadata).
Out of curiosity, can you provide a link to your station? I have created a website for listening lossless internet radio stations: https://audiophile.fm
For FLAC, latency is primarily driven by block size and the library's own internal buffering.
Using the API you can set the blocksize, but there's no manual flush function. The only way to flush output is to call the "finish" function, which as its name implies - marks the stream as finished.
I actually wrote my own FLAC encoder for this exact reason - https://github.com/jprjr/tflac - focused on latency over efficient compression.
The technique is also used in Discord RPC Bridge for Wine - allows Wine apps to communicate with Linux Discord - https://github.com/EnderIce2/rpc-bridge