61–69 of 69 posts
Still remember the days where one had to compile the kernel to enable sound in doom. The fact that most hardware is supported today is a blessing. And agree with the author. X11 has aging issues.
Yea, that's cute, except that DRM can handle pretty much all of it. You can split hairs and complain about GPU scheduling which is inherently rather difficult because scheduling at the command queue level is problem very much alike the halting problem. The real issue isn't that we don't have the pieces we need but rather that we can't get all the players to agree on using the same ones. On Windows you have one entity…
People very smart, knowledgeable, wise, persistent, patient, cleaver, prudent etc. have been able to manage organizations with different concerns, priorities and goals.
"Bandwidth Limit Exceeded The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later."
Earlier quoted context omitted.
Slackware 2.0 was released in August 1994. Even 1.0 (which is probably the first distro to have XFree86) was released in July 1993. I used MCC before that and I don't think X was available (though, to be fair, I can't really remember when I first got X working on my machine). I distinctly remember having to wait until mmap() was implemented before anyone could even think about getting X to work. :-) It is quite possi…
If you wanted basic 2D stuff yeah, then there were the adventures with hardware accelerated 2D and the first batch of 3D accelerator cards, followed by first generations of integrated 2D/3D cards. It wasn't just getting the monitor refresh rate working.
I started using 3D acceleration when Compiz/Beryl was released (2006) with an NVidia card. I was playing World of Warcraft under wine at that time too. The only problem I had was when I updated the kernel I had to remember to recompile the drivers under Debian. I switched to Ubuntu for that reason (because then I didn't have to do anything).
Eventually I retired that and went with an Intel board. It worked 100% but was dog slow at the time (pre-2010 Intel drivers were quite good at 2D acceleration but abysmal for speed at 3D). Compiz worked perfectly, the only problem was a pretty big hit in frame rate for WoW.
I replaced that with a Radeon Card which worked perfectly under Catalyst. I started hearing rumours that the free software drivers were getting good performance numbers and switched to that. 2D was amazing (dramatically better than Catalyst) and 3D was slightly slower, but comparable.
Finally replaced that with a few laptops running Intel hardware again. By this time (2012) the 3D performance had dramatically improved and I'm quite happy with it. Obviously not a gamer set up, but more than adequate for casual gaming.
Before 2006, I think you were pretty much stuck with Nvidia and proprietary drivers if you wanted 3D. Again, I never heard anyone who had real problems other than recompiling the drivers if you were on a distro that didn't do it for you.
I actually worked with Gavriel State at Corel before he started up TransGaming. I thought he was completely nuts to do it because at the time there was almost nothing that ran under Wine properly. That was 2001. Honestly, if you were trying to get 3D working on Linux, you were mostly doing it just to say you did it.
I'm not going to deny that some people had problems with video cards. I often had to jump through hoops to get random hardware at work to give me nice displays. But if you were careful to buy supported hardware, there were very few problems.
To be fair, I did a lot of Windows development in the late 90s and early 2000s and I had at least as many problems with video drivers under Windows. The difference was that on Linux I would have trouble with new hardware, while with Windows I would have trouble with old hardware. The other big difference is that with Linux, you could almost always get something to work so that you could hack on it. With Windows, getting to a point where you could download updated drivers could be unbelievably painful.
Earlier quoted context omitted.
Anecdotal, but these "compositor problems" are not inherent to Linux or X11. I am extremely sensitive to things like tearing, and I can tell you it simply doesn't occur on my linux machines (though it does require enabling a TearFree X11 option on my intel GPU). Wayland, unfortunately, seems to be the type of project that has been a year or two away from usability since its first release in 2012. I suspect we'll be s…
The open source Radeon driver also does a good job of avoiding tearing. I think there are some pathological cases where it can still occur, but it is pretty rare. Catalyst was terrible at avoiding tearing the last time I used it (getting on to be 3 years ago now). I haven't looked into it, but it is possible that the tearing issue may not be solvable without a KMS driver (i.e. no binary blob drivers can do it). I use…
http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...
Earlier quoted context omitted.
I'm having a very hard time imagining there exists even a single program out there that depends on being able to read the memory contents of a program that ran before itself. I bet it comes down to driver developers never even thinking that this could be a security issue before people came up with the concept of running unauthenticated 3d accelerated software (i.e. javascript+webgl from the network in a browser) - "w…
Reminds me of GO.COM ( http://peetm.com/blog/?p=55 ) That is/was an example. GO.COM contained no program bytes at all – it was entirely empty. However, because GO.COM was empty, but still a valid program file as far as CP/M was concerned (it had a directory entry and file-name ending with .com), the CP/M loader, the part of the OS whose job it is to pull programs off disk and slap them into the TPA, would still load…
SAVE 0 X.COM
This is a good example of one of the dangers and failure points of open source. When hardware integration matters, you're going to have sub-par results if you don't have a strong relationship with the hardware manufacturers. The best firmware is from companies that control both the software and the hardware. Linux fundamentally cannot have this relationship. Some things need to be very specifically controlled and des…
a. Graphics requires software and hardware to be integrated
b. Open Source communities don't work where you are driving designs in software and hardware - they are uncoordinated
I can't comment on (a). In terms of (b) you might be right for the idea of "hackers at night" open source. But, a lot of open source is 'professional', so a graphics company could solve this by:
1. Graphics companies provide hardware and information under NDA to specific Open Source developers. That gets you enablement but not necessarily a "design" as you can't direct their work.
2. The hardware companies hire Open Source developers. That way you have either all, or a big chunk of a specific area of the developers. As employees they will work together on the companies priorities.
3. The hardware companies set-up a foundation. Then the foundation co-ordinates and works on the priorities of the members. There are sub-groups of the Linux Foundation that work like this - for ARM Linaro is an example.
There's a meta-comment that talks about the economics of this area - that's a more significant challenge than the organisational ones.