Similar to the Political Bureau in former communist countries, but still an autocracy.
> But I wouldn't call it an autocracy.
It has most certainly started to walk and quack a lot like an autocratic duck, it wasn't the case 10 to 15 years ago, or not as visible, to say the least, but the pandemic and this recent war in Ukraine have changed that.
I think it's healthy, even necessary, to utterly distrust microsoft (or any large compny, for that matter). And while I don't think it's a-ok to call an individual microsft employee a monkey by name I think it IS a-ok to say any microsoft product is 'written by monkeys' or any other suitable derogatory term.
The way github develops is steered by microsoft-the-company and not so much by it's individual employees. A company, especially such a huge one, is not to be trusted and can (should) be made fun of.
All companies are 'a group of people'. But that's not how you treat them. You should treat the individual employees of microsoft as the people they are. You should treat microsoft as a whole as the evil entity it is (TBF they're not worse than apple or google or etc...)
You should also consider the point of view of anyone working on github and being paid by microsoft but who actually does care. Note that they are not named and shamed or anything like that.
Do you think there is a chance these hypothetical engineers who care actually want this kind of thing said publicly? And said as poetically invictive laden as possible? The rationale being that they might use such sentiment to get management to see the danger and /start/ caring about product quality?
I've never worked for microsoft. In my experience when product goes into quality decline, rubbish management is >90% of the reason. How futile is fighting that? How futile is fighting it for github? Does github matter in general? My own use is so limited it doesn't directly matter to me. Indirectly it might well do.
The problem with 'something like SDL, but 3D' very quickly turns into a full blown engine. There's just such a combinatorial explosion of different ways to do things in 3D compared to 2D that 3D 'game engine' is either limiting or complicated.
OpenGL was designed as a way to more or less do that and it turned complicated fast.
Here in the netherlands as soon as you try to do something, the farmers start flyingh upside down flags. I call them the 'head in the sand' flags since they stand for ignoring the problems.
I fear the problem is just that the earth suffers from an infestation of humans and the equilibrium will be restored in the same way all infestations end. It won't be pretty (already isn't in lots of places).
I think I remember there was some communication between ID and Charles Sandmann about CWSDPMI, so even though it's worded a bit strange for an open source project there's probably some thruth in it?
Also a bit strange how the author is surprised about Quake running in a 'VM', apparently they don't really know about VM86 mode in x86 processors...
Is the author surprised by that, or did you just misread it? The only relevant quote on that page that I see is “It is impressive to see Quake run at full speed knowing that Windows 95 runs DOS executable in a virtual machine.”
He is perhaps surprised that it runs _at speed_ in the VM, not that it runs in the VM which he already knows about.
I think if you're relatively young is hard to know computing history. Its oddly older than one thinks, even concepts that are seen as new. Its sometimes interesting to see people learn about BBS's which flourished 40 years ago.
It's a bit surprising because this is the author of the DooM Black Book and they know the underpinnings pretty well.
However, the difference between a DOS VM under Windows 9x and a Windows command prompt and a w32 program started from DOS is all very esoteric and complicated (even Raymond Chen has been confused about implementation details at times).
So... Win32 runs in virtual mode. In 2025, we don't think of that as a Virtual Machine, but it totally is. Hardware access is trapped by the CPU and processed by the OS/DPMI server.
It's not a virtual machine. There is no hardware machine that presents itself to function like a protected-mode ring 3 task on an 80286 or an 80386 functions. And the 286 and 386 both lacked a "virtual 286" and "virtual 386" mode (although it would have been almost-trivial for them to support it; Intel just decided not to, probably figuring it wasn't important).
Virtual 8086 mode, on the other hand, does behave exactly like a real 8086, which otherwise would have been very slow to implement on a real 386, and was either very slow on a 286 or impossible due to the 286 having some errata that prevented normal virtualisation techniques (the 286 had some non-restartable exceptions).
Only if they never call DOS or the BIOS or execute a Real Mode Software Interrupt. When they do, they ask the DPMI server (which could be an OS like Windows 9x or CWSDPIM) to make the call on their behalf. In doing so, the DPMI server will temporarily enter into a VM86 Virtual Machine to do execute the Real Mode code being requested.
But that's not the DPMI client running in a VM. That's the host ending up running in a VM.
Note that in a machine with EMM386, the machine is normally running DOS inside an 8086 VM... and the only reason it would switch out of that VM is when you fire up a DPMI client.
VM in this usage means Virtual Memory - i.e. with page tables enabled. Two "processes" can use the same memory addresses and they will point to different physical memory. In Real Address mode every program has to use different memory addresses. The VM86 mode lets you to have several Real Mode programs running, but using Virtual Memory.
VM does not mean Virtual Memory in this context. VM does mean Virtual Machine. When an OS/DPMI Server/Supervisor/Monitor provides an OS or program a virtual interface to HW interrupts, IO ports, SW interrupts, we say that OS or program is being executed in a Virtual Machine.
For things like Windows 3.x, 9x, OS/2, CWSDPMI, DOS/4G (DPMI & VCPI), Paging & Virtual Memory was an optional feature. In fact, CWSDPMI/djgpp programs had flags (using `CWSDPR0` or `CWSDPMI -s-` or programmatic calls) to disable Paging & Virtual Memory. Also, djgpp’s first DPMI server (a DOS extender called `go32`) didn’t support Virtual Memory either but could sub-execute Real Mode DOS programs in VM86 mode.
I agree that my comment about VM was imprecise and inaccurate.
I do dispute your assertion that virtual memory was "disabled". It isn't possible to use V86 mode (what the Intel Docs called it) without having a TSS, GDT, LDT and IDT set up. Being in protected mode is required. Mappings of virtual to real memory have to be present. Switching in and out of V86 mode happens from protected mode. Something has to manage the mappings or have set it up.
Intel's use of "virtual" for V86 mode was cursory - it could fail to work for actual 8086 code. This impacted Digital Research. And I admit my experiences are mostly from that side of the OS isle.
I did go back and re-read some of [0] to refresh some of my memory bitrot.
Slight nitpick: you could run fire up V86 mode without any LDT entries.
It's also possible to run Virtual 8086 mode without paging enabled, and when in Virtual 8086 mode, the 386 doesn't care about what's in the LDT/GDT (unless an interrupt happens). In practice this is never done because the Virtual 8086 task would only be able to use the bottom 1MB of physical memory.
Slight nitpick: OS/2 2.x+ did not have a way to disable paging, although you could disable virtual memory in any version of OS/2 by simply setting MEMMAN=NOSWAP.
On Windows 3.x, paging and swapping was optional - if you started it in 286 ("standard") mode. On Windows 95, paging is not optional, and it's not optional in Windows 3.11 for Workgroups either.
While there's sometimes maintainer-prima-donna egos the contend with there's also this:
Any patch sent in also needs to be maintained into the future, and most of the time it's the maintainers that need to do that, not the people contributing the patch. Therefore any feature-patches (as opposed to simple bugfixes) are quite often refused, even if they add useful functionality, because the maintainers conclude they will not be able to maintain the functionality into the future (because no one on the maintaining team has experience in a certain field, for example).
The quality bar for a 'drive by patch' which is contributed without the promise of future support is ridiculously high and it has to be. Other peoples' code is always harder to maintain than your own so it has to make up for that in quality.
Not any patch. Sometimes there are patches that are not explicitly fixing defects, but for example they surface a boolean setting that some upstream library started to expose. That setting is exactly like a dozen other settings already there. It's made using the same coding style and has all requisite things other settings have.
Maybe the developer intends to some day change the internal implementation, such that that particular boolean flag wouldn't make sense any more. Or they're considering taking out the option entirely, and thus simplifying the codebase by making it so it only works one way.
Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work? I'm not your employee. Your product doesn't put a roof over my head.
I don't want a job where I do free work, for a bunch of companies who all make money off my work. That's a bad deal. Its a bad deal even if my code gets better as a result. I have 150 projects on github. I don't want to be punished if any of those projects become popular.
We can't go around punishing projects like ffmpeg or ruby on rails for the crime of being useful.
> Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work?
Then say you don't expect contributions at all. That's a fair game, I'm ok with it. I will then exercise my rights granted by your license in another way (forking and making my own fix most likely). My gripe is with projects that write prominently "PRs welcome", and then make enough red tape to signal that nah, not really.
The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life.
Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism, and polarization, I just as increasingly want to have no part in them most of the time.
I think many projects would be better for having a lane for drive-by contributors who could work on fixing bugs that prevent their day-to-day from working without expectations of becoming full-time engaged. The project could set an expectation that "we will rewrite your patch as we see fit so we could integrate and maintain it, if we need/want to". I wouldn't care as long as the problem is taken care of in some way.
In my experience simple bugfixes are nearly always accepted without fuss (in active projects, that is. Some project in maintenance mode where the last commit was 3 months ago is a different story, because then probably just no-one can be arsed to look at the patch).
Some simple setting expose like you describe can sometimes go in without a fuss or it can stall, that depends on a lot of factors. Like the other reply states: it could go against future plans. Or it could be difficult for the maintainer to see the ramifications of a simple looking change. It sucks that it is that way (I have sent in a few patches for obscure CUPS bugs which have stayed in limbo, so I know the feeling ;-) ) but it is hardly surprising. From a project's point of view drive-by patches very often cost more than they add so to get something included you often need to do a very thorough writeup as for why something is a good idea.
> I just as increasingly want to have no part in them most of the time.
If all people you meet are assholes.... ;-P Not to say you are an asshole, or at least not more than most people, but I have been in this situation myself more than once, and it really pays to stay (overly) polite and not let your annoyance about being brushed off slip through the mask. The text-only nature of these kind of communications are very sensitive to misinterpretations and annoyances.
It would be nice if all you'd need for a patch to be included somewhere was for it to be useful. But alas there's a certain amount of social engineering needed as well. And imho this has always been the case. If you feel it gets increasingly hostile that's probably your own developer burnout speaking (by do I know that one :-P )
“Pay my way or take the highway” is as close to the closed-source ethos as you can possibly get. Collaboration is not feasible if the barrier of entry is too high and those involved make no effort to foster a collaborative environment.
Yes, because with a closed source you can also just download the source and add your own patches and maintain your own fork... /s
Most open source projects have way more patches contributed than the core developers can handle, so they tend to only accept those from the friendliest contributors or with the highest code/documentation quality.
reply