Containers for Windows
-
Yes, there is no mandatory file lock in Linux that I am aware of. How is it done in Windows? Does that mean I can lock a file that cannot be deleted even by root? I guess that is something Malwares would like to use.
All files are locked when you open them, either with a Read lock or a Write lock as appropriate. You can also read from a file that is being written by explicitly requesting to do so. If you want to write to a file that another program is already writing to, it doesn't matter what permissions you have, it will not work. If you really want to alter the file, then you need to stop the other program first.
As for malware: If you're trying to remove malware while it's still running, you're doing it wrong.
Without locks the malware could simply check its executable is modified and take measures to repair itself anyway.
-
All files are locked when you open them, either with a Read lock or a Write lock as appropriate. You can also read from a file that is being written by explicitly requesting to do so. If you want to write to a file that another program is already writing to, it doesn't matter what permissions you have, it will not work. If you really want to alter the file, then you need to stop the other program first.
Incorrect. Almost entirely. Jesus.When you try open a file, you request both an access mode (
GENERIC_READ,GENERIC_WRITE, both, neither, or any collection of access bits you like) and a share mode (any or all ofFILE_SHARE_READ,FILE_SHARE_WRITE, orFILE_SHARE_DELETE, or0). If the file is already open, and your access mode is compatible with all other share modes, and your share mode is compatible with all other access modes, then it succeeds. This does mean you can open a file withFILE_SHARE_DELETEand be in the middle of writing to it when something else deletes it; the file sticks around until you close it and then it's deleted. If you open a file withGENERIC_WRITEandFILE_SHARE_WRITE, and so does someone else, then you both can write to the file all day long. You might end up corrupting it, but as long as you stick to different portions of it it works fine.
-
I guess something like
O_EXCLUSIVEwould be handy, sometimes. But at the same time this is protecting a user against himself, because otherwise ownership will protect it anyways. If I want to make sure no other application messes with my file I could open it under a different access right.This does mean you can open a file with FILE_SHARE_DELETE and be in the middle of writing to it when something else deletes it
This is new to me, I was not aware that this can be done in Windows! In Linux this is the default anyways, because you
unlinkit which decreases the refcount;inodewill still live until application closes it.
-
Ever heard of an ioctl(), dickwad?
I didn't realize that all those years Linux people were telling me, "everything in Linux is a file!" that they were fucking liars.
-
The fact that you can perform an ioctl() on a file handle doesn't make it less of a file handle.
-
I didn't realize...
Surprising precisely no one.
...that all those years Linux people were telling me, "everything in Linux is a file!" that they were fucking liars.
It's more that your language processor fries when it encounters figurative language.
-
Looks pretty broken to me.
Locking between non-cooperating processes is really hard to get right. Ignoring the whole problem of networked filesystems (where locking is many times more difficult) by the time you've got stuff enforced to be in the patterns that won't leave everything open to deadlocking in the first place, you don't need mandatory locking. In short, it's not a big problem.
Mandatory locking needs to be turned on for a particular file before you can use it; it's one of the permissions flags. It's switched off by default. This means the only thing a badly-behaving program can do is get shared locks on things that other parties aren't usually locking in the first place, or get a writer lock on files that they can already write but in that case they can cause greater mischief anyway.
But yes, POSIX fucked locking over hard. (Linux is following a broken spec here.)
-
It's more that your language processor fries when it encounters figurative language.
Awww, c'mon, nothing goes over his head. He would catch it.
-
I think there are two major problems to MSIs:
-
The documentation is piss poor to the point it is fucking impossible to get started unless you buy something like InstallShield or you have a legacy installer to maintain. I REALLY hate saying that, InstallScript is the second-coming of the anti-Christ, but it is magnitudes better than raw Windows Installer.
-
Microsoft sent A-Team people to develop what ended up a C-Team product. Consider making a MSP for a product because you need to send out a quick fix? I've never figured out how to do it without something like InstallShield and that assumes the base installer I started with wasn't shot to shit from the beginning. All I want to do is update 3 files, WHY IS THIS SO HARD!
-
-
App A should not talk to card, but should open /dev/video0 and use that to ioctl the channel 5.App B should not talk to card, but should open /dev/video0 and use that to ioctl the channel 7.Driver should realize these are 2 file descriptors, so when App A reads /dev/video0 should fill it with channel 5 (similarly fill it with channel 7 for App B).
For all that matters a dumb app can open both channels at once, each a different channel, or maybe it wants to overlay one on top of the other (like a little preview), so it is not that dumb after all.
@Blakeyrat's point is that most TV cards, due to hardware limitations, can't decode two channels at the same time. So driver has to somehow lock access to the virtual file output stream to application B, if application A is already using it.
Otherwise, you get into a situation that @TimeBandit is describing.
EDIT: Never mind, I should have read to the end before replying. I blame Discourse.
-
I blame Discourse.
Don't we all
On Topic: This guy seems to have figured out how to fit a Window on a Container
-
..., driver should provide a transparent way to multiplex between users (with potential quality drop, but with clever zero copy it actually is most of the time Ok). But if there is absolutely no way, it should throw an
file access errorwhenopening/dev/video0This is what happened with the old OSS sound thingy. /dev/dsp or whatever it was on Linux didn't do multiplexing or anything if the sound hardware didn't have hardware mixing and opening it more than once at the same time threw the busy error. If you were one of the fortunate ones with something like SoundBlaster Live! that had real hardware mixing you could mostly ignore all sound related issues because that shit just worked damn well.
Then there were two or more attempts (arts, esd, insert more) at solving this by having odd sound servers with shitty APIs and even shittier OSS emulation and laggy throughput where the sound server did software mixing and applications were wrapped with the (broken) OSS emulation layer which usually resulted in distortion and lag. Even though all servers had some "native" API no app really ever used it except some special cases because you'd need to have like four different ways to output some fucking sound.
The came ALSA, another kernel API that was complex, even shittier than OSS and new hardware didn't support OSS anymore and old apps didn't support ALSA. It had broken software mixing (dmix) and an API that usually caused some sort of distortion and again OSS emulation that caused even more distortion. This shit pile was used for around 10 years or so.
Now ALSA is still there, not-too-old applications have slowly dropped support for all legacy sound servers and only have ALSA support. Though, because ALSA is still as shitty as it was before, PulseAudio was born to give us AGAIN a new sound server. It has broken ALSA emulation yet again and all legacy-ish applications that only have OSS/ALSA support go through that. Fortunately it's relatively lag free and at best just works. Switching output per application and controlling volume level actually works if for god sake you have PA output support in your app it works relatively well.
It took like 20 years to go full circle and we again have a shitty kernel API and a sound server that does software mixing hiding all the shittiness of the kernel API.
I've had to use all incarnations of this shit and can at least say the current situation it A LOT better than anything before, even though it still works around the official Linux sound API...
-
Fortunately it's relatively lag free and at best just works.
That really depends on your hardware. On my laptop, PA works okay enough. On my desktop, PA introduces ~100ms latency (okay, that's totally fine) that varies by +-20% (okay, that's totally not cool). This doesn't happen on Windows, and it doesn't happen when I kill PA and use JACK.
I've changed to JACK on both machines, and am making use of the JACK<->ALSA bridge for non-JACK-aware software. I'm substantially more happy with the results. I do lose the ability to do per-application volume control in kmix, but I can manually set up such a thing with jack_mixer, so it's totally possible to do automatically, but just hasn't been done by the kmix folks.
Guess I have my next project for when I get a pile of round tuits.
-
All I want to do is update 3 files, WHY IS THIS SO HARD!
It might be for the same reason Windows didn't ship with even the most basic CD burning software until Windows XP or so, and -IIRC- Windows doesn't ship with CD image mounting software: MSFT doesn't want to anger the folks who make their third-party-software "ecosystem".
Better to ship a poorly documented pile of legos that enables enterprising third parties to drink from an unending money fountain than to let anyone use your software by properly documenting it and giving it a sane developer-facing interface.
-
I remember that hell :) well I used to dual-boot for a reason. It took long, I think because companies did not care about the small user-base in Linux desktop: multimedia in Linux sucked, but server was great. Good software needs paid developers. Now with Android, Steam (and Chrome OS) companies will think twice.
If I am a developer putting together a system to run Android (say it is In-Vehicle-Infotainment, or smart TV, or smart watch, or ...) and the chip in an audio device (or video or bluetooth) is not out-of-the-box working great, most likely I drop it from BOM and find one that works.
-
Fortunately I'm in the group where all PA related just works, including Wine with wine-pulse which is still missing from upstream because reasons.
JACK should've been where PA currently is. Doesn't Apple use it so it can't be worse than what the previous mess of sound servers were?
-
JACK should've been where PA currently is.
Agreed. For the longest time, I didn't use JACK because I had the impression that it was devilishly difficult to configure. When I went to use it, I found that it was substantially easier than configuring Pulseaudio back in the ~0.9.7 days. (Indeed, qjackctl makes it so you don't really even have to read the jackd manual. ;) )
Doesn't Apple use it...
I don't know if you're referring to JACK or PA, but a quick search doesn't raise indications of Apple using either one in OS X. I wouldn't be surprised if my search terms sucked.
-
Don't confuse business decisions with derp-developer decisions. Allowing idiots to point guns at their feet is the Microsoft Raison d'être. The problem is they let the uber-nerds develop the product to the point of un-usablity(much like duck-sauce). It shouldn't require a C compiler + a Grep/diff util to make a fucking binary patch. But with Windows Installer, it does. And that is bad.
No sane person writes raw MSI, they use InstallShield, WiX, Bitrock, etc. Granted 99% of the time you just need stuff copied onto the system but even that can get REALLY complicated when you throw versioning in.
Upgrades are non-trivial tasks.
-
Allowing idiots to point guns at their feet is the Microsoft Raison d'être. The problem is they let the uber-nerds develop the product to the point of un-usablity...
MSFT does create power tools, yes. However, I can't agree with the second sentence in the quote. From what I've read MSFT is absolutely caked with layers and layers of bureaucracy and red tape. "Nerds running wild" is -as I understand it- not a thing that happens there.
Upgrades are non-trivial tasks.
If you wish to upgrade from version A to version Z, and you have instructions for upgrading from A->B, from B->C, from C->D, and so on down the line, then the upgrade process is trivial, but -perhaps- time consuming. Always first make correct software, then make that software fast.
Or were you speaking from the perspective of the installer author? If you were, then why should creating an upgrade package be more complicated than writing down the objects to be removed, replaced, and added, the services to be stopped, restarted, and started, and in which order all of these operations are to be performed?
Tedious? Yes. Much to keep track of? Sure. But the complexity is unavoidable: this is work that you have to do if you want to upgrade, rather than uninstall-the-old-and-install-the-new.
-
"Nerds running wild" is -as I understand it- not a thing that happens there.
I have to agree; it us in the Linux crowd that are easily accused of that (mostly by @blakeyrat). MS typifies a company run by marketing directors, not nerds, a management style they learned from Big Blue eons ago. Some would say that they are run by big egos, but that's more Oracle's style (and Apple's, but the egos in question at least listened to their UX designers). Microsoft actually does do a passable job of UX (which is all they need to do to), but they are willing to throw it away whenever marketing wants to screw with things.
-
The problem is they let the uber-nerds develop the product to the point of un-usablity
Compared to what? Linux?
-
So driver has to somehow lock access to the virtual file output stream to application B, if application A is already using it.
So… it's like only allowing one process to have the device open for read-write at a time?
-
So… it's like only allowing one process to have the device open for read-write at a time?
Either that, or just allow multiple readers, one writer / controller.
-
Either that, or just allow multiple readers, one writer / controller.
That was what I was implying. Pure readers would get to peek on the stream as it goes past (and would be able to ask for metadata about things like frame-rates and so on) but would have no option to control. Either what's going past is something you can do something with, or it isn't in which case it
sucks to be youis time to give up on reading.I think that locking a device's writer to a single process would be doable. I don't know if that's an idiom currently in use though.
-
I think that locking a device's writer to a single process would be doable. I don't know if that's an idiom currently in use though.
-
Why doesn't Discourse's "highlight to quote" feature copy the formatting of the quoted text? I had to manually fixup the quote.
-
I'm fairly certain that if you're writing the device driver, you get to determine what happens when someone tries to open the device node for your device. You can return EACCES to all open-for-writing attempts unless it's 12:01 on the third Tuesday of the month, if you like. I know that there are nodes under either /sys or /proc that are root-writeable, but return failure when root attempts to write to them, unless certain conditions are met.
It wouldn't strike me as very strange if I ran into a device that behaved in the way you describe your theoretical TV tuner behaving.
-
-
Why doesn't Discourse's "highlight to quote" feature copy the formatting of the quoted text?
If you want to report that as an issue on meta.d — and to be fair, it is quite a visible one to an ordinary user — then be our guest. I wouldn't really expect a particularly professional response, but my pessimism might be unfounded.
Cite: Well, far too many threads for me to ever pick one out…
-
@MathNerdCNU said:
The problem is they let the uber-nerds develop the product to the point of un-usablity
Compared to what? Linux?
I'm going to have to side with Blakey this time; no matter what anyone else says about unices, it is usually shit for UX (MacOS being the only real exception that has any noticeable user share). While it is possible to do UX well on Linux, there are two major problems: first, that Unix devs rarely know anything about UI design and CBA to do it even when they do; and the flexibility that is the major advantage of *nix ends up being a hindrance in this case, as the only way to do it well as a developer is to chose one DM and fuck everyone else using a different environment. Even when it does work, it takes expert administration to make it work well, like everything in the Linux world. IOW, Linux is great for someone with tons of experience in Linux, but the learning curve is punitive for anyone who isn't a developer, and even devs are going to be in for a rough time. For some people, like me, it is worth the effort; it will never be for the 90% of casual users who just want something that works OOTB, especially if they just need Word and a web browser.
There are a handful of Linux-based systems that are that turnkey, but most of those are hidden behind a specialized and often single-purpose interface (Android phones and tablets, Tivo, OLPC X-O laptops, and such like). The very few companies that give a decent novice Linux experience pre-installed (System76, ZaReason, Eight Virtues) bend over backwards to get it, and end up costing more for a 'free' desktop or laptop than the equivalent Windoze system. It's a hard truth, but a truth nonetheless.
-
-IIRC- Windows doesn't ship with image mounting software
It does since Win8. AndI think the reason is simpler - CD burners weren't that ubiquitous before XP as far as I remember, and ISOs I guess they needed to do eventually since Microsoft Store uses them.
-
especially if they just need
Word anda web browserFTFY. Google Docs is getting pretty good for the 99% case. (There's one or two things that I miss — from my current stuff, two-column pages and proper references sections — but not much at all.) If they're that good, there must be alternative providers that are reasonable too.
-
Word/Excel Online are good as well if you have a subscription. I use them on Linux when I need to touch some work documents. Together with OneDrive it works fairly well, except when OneDrive decides everything is in conflict for no apparent reason (personal files).
-
My favorite thing about OSX is that it's open source, and even so, no one cares enough to use it.
-
My favorite thing about OSX is that it's open source,
Well, it's closed source, so guess that sucks for you?
Darwin is open source though.
-
Okay? Is there an actual distinction you're trying to make, there?
-
-
He's probably making the point that the OS kernel is pretty much the LEAST important part of the OS proper. Just like people don't buy houses based on the materials used in the foundation, people don't use an OS based on the features in the kernel. (Generally speaking.)
All of the stuff that makes OS X OS X isn't open source.
-
And I'm making the point that making something open source is dumb, because it's likely no one will ever touch it. It ends up just being a tag you can put on things to say 'hey look, we're hip!'
-
...and ISOs I guess they needed to do eventually since Microsoft Store uses them.
ISTR MSFT "shipping" installation ISOs for products long before Windows shipped with any sort of software to handle said files.
-
If you want to report that as an issue on meta.d — and to be fair, it is quite a visible one to an ordinary user — ...
Given how easy it is to run into this bug and how trivial it is to repro, and given that the Discourse crew almost certainly use the software that they write I cannot imagine that Attwood & co. are unaware of it.
I think that this is a long-standing issue, so it smells like the software is behaving as intended.
This is a really long-winded way of saying: "No. I'm not going over to meta.d to get yelled at and banned for finding a bug."
-
“Containers” exist in Linux solely because of the dependency hell that is Linux, whereas Windows never had that problem thanks to a registry, COM, and tremendous number of other things that NT got right thanks to starting in ’93 instead of ’73 (and obviously, b/c Dave Cutler was familiar with the idea of "design", as opposed to "hacking shit until it works on my machine").
Containers claim to provide better process isolation and help with security.
It happens to be used to make install and uninstall simpler, and I would enjoy being able to install software like visual studio and sql server in containers, because they leak all over the OS and the uninstall never get you in the same place you were before you started. I already have to format a machine after installing a beta version of some MS software. It would be great not have to trust an app to uninstall correctly on windows.
Also, distributing DLLs in your application to avoid dependency problems can be done with Linux, just like people do with windows sometimes. They avoid doing it because its unlikely that dlls in your application folder will receive security updates. It's a trade-off in this case.
-
It's a trade-off in this case.
It's precisely a trade-off. If you share things, you get the benefit of shared updates. If you share things, you have to deal with the possibility of getting stuck with a version you don't like. These things are coupled strongly. Improve the isolation, lose the ability to pick up on an improving environment.
