TC 8 already :)

[pq5190362]

Well, I'm looking forward to an updated graphics stack, or whatever might fix the broken i945 drivers /dri issues.

Maybe you could use dCore-xenial and use the Oibaf PPA, which always has the latest git versions of Mesa/DDX. Or does that PPA not work on dCore-xenial? According to the Wiki, PPAs should work: http://wiki.tinycorelinux.net/dcore:ppa-add_command

[curaga]

I offered to help and support TinyCore, why would you push me to another distro? Perhaps you read my comment as a complaint, but it was meant as a suggestion for improvement with which I can definitely help.

It's just how I see it, a volunteer distro cannot ever match a paid one for secure servers, etc. Even Debian with its manpower is usually slower than RHEL or Suse.

What's your use case? You mention that local kernel vulnerabilities concern it.

[andyj]

What I can say about security is that I'm maintaining Apache, Postgresql, PHP, bind, dhcpd and lighttpd for TC 64 and I'm keeping them current because I need them to be. What I can also say is that putting together a build box isn't a big deal in TC. If security is important to you and you have preferred packages I'm sure the community would appreciate the help. I know a lot of people use TC for real world applications, and we know why we're not using fat distros. TC is more of a community effort than it would appear to be on the surface. I disagree that the paid distros are more secure. They have way more packages than a server needs so they require more updates. The beauty of TC is that the very small amount of software reduces the attack surface and so security should be easier since so few packages per server would need updating.

My $0.02 input for TC 8: Unify the 32-64 bit installer. The 32-bit installer will work for both if the install paths are tweaked just a little. I posted my solution here a while ago: http://forum.tinycorelinux.net/index.php/topic,19738.msg122475.html#msg122475

[jls]

Maybe you could use dCore-xenial and use the Oibaf PPA, which always has the latest git versions of Mesa/DDX. Or does that PPA not work on dCore-xenial? According to the Wiki, PPAs should work: http://wiki.tinycorelinux.net/dcore:ppa-add_command

ppa works under dCore

[nitram]

Forgive this off-topic reply, this thread is now officially off-the-rails. Despite dCore being slightly heavier than TC, my old graphic hardware never worked better in dCore-jessie and stretch, as the required packages are readily available for import to make things work. For me it was Mesa related libraries. Misalf you may want to install dCore-xenial or stretch, test glxgears, SMPlayer or other benchmarking software and see what other imported packages may be required to make it work welll again. If you identify the culprit(s), then just provide the required extensions for TC8.

[Misalf]

Doesn't seem like a dep related thing though. More like a X / driver related thing. I've bloated everything out of Core that I could think of but there is no way to make 3d work. Would be a shame if 6.x would be the last release to provide 3d on crappy old intel integrated graphics.

[pq5190362]

Doesn't seem like a dep related thing though. More like a X / driver related thing. I've bloated everything out of Core that I could think of but there is no way to make 3d work. Would be a shame if 6.x would be the last release to provide 3d on crappy old intel integrated graphics.

Suggestion:

1. Download the ISO of the current daily build of Ubuntu 17.04 Zesty Zapus (which is using Kernel 4.8 at the time of writing this):

Unity version:
http://cdimage.ubuntu.com/daily-live/current/
GNOME version:
http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/
KDE version:
http://cdimage.ubuntu.com/kubuntu/daily-live/current/

2. Burn the ISO to a USB stick
3. Boot from the USB stick into the live OS (i.e. "Try Ubuntu without installing")
4. Check if 3D works
5.1 If it works: Then most likely the Kernel/DRM/Mesa/DDX stuff in Tiny Core Linux is outdated and is causing the issues
5.2 And if it doesn't even work on Ubuntu 17.04: Then maybe you should submit the issue on the freedesktop.org upstream issue tracker with setting Product to DRI via https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and setting Component to DRM/Intel
6. Let us know about the outcome 

[Juanito]

I'm reasonably sure that the problem is the kernel driver

[Misalf]

May the inclusion of i915 to gallium provide a useful fallback, in case there won't be any improvements or fixes for intel gen3 integrated graphics?

[Juanito]

Maybe this is answering a different question, but I noticed that if I load xf86-video-vesa and not xf86-video-intel, Xorg-7.7 uses the modesetting driver and I don't get the intel kernel driver errors.

Did you try that?

[pq5190362]

but I noticed that if I load xf86-video-vesa and not xf86-video-intel, Xorg-7.7 uses the modesetting driver

You don't need to install any xf86-video-* DDX at all to land on xf86-video-modesetting.

As already discussed in another thread, xf86-video-modesetting is included in xorg-server now, so it will automatically be used if no other xf86-video-* DDX is installed.

xf86-video-modesetting (which defaults to DRI3 and uses Glamor for acceleration) + Compton is working very well on Intel hardware by the way, even better than xf86-video-intel.

As suggested by AMD employees, Compton runs well with the following options:

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/911776-amdgpu-radeon-ddx-updated-better-2d-performance-tear-free-dri3-default/page5

[Misalf]

Yes, I tried modesetting. I have to explicitly specify it via xorg.conf though.
Anyhow, it's terribly slow.

nitram informed me that the gallium driver was compiled without support for i915
--with-gallium-drivers="nouveau,r300,r600,radeonsi,svga,swrast,[swr]"

For me, all this is quite puzzling. That's why I'm asking if it would make any sense to add support for i915.
Of course, the intel driver would be preferable for me if it will work in TC 8.

[curaga]

It's just being removed? You don't want to use it, it never reached production quality.
http://www.phoronix.com/scan.php?page=news_item&px=Intel-ILO-Gallium3D-Dropping

The official Intel driver is the non-gallium one.

[Jason W]

I have seen this thread today, and I have an observation.

pq5190362 - Please don't engage in Core versus dCore, I don't encourage or allow it in the dCore area, and the same goes for the main Core forum.  Thank you for your interest in dCore.  But main Tinycore/Core is the 'real deal', and I like interest in dCore but dCore is a secondary offering that is based on Core.  So there is no competition.  Thank everyone for understanding.

[hiro]

it's a usual tactic i observe in open source projects: tell all slightly-related projects that the other competing projects are better. they don't look at why or care about any technicalities. they just think they do it for the greater good, that people will get back to work and then make more useful software (i.e. support their crappy feature request), cause all that was needed for greatness is their friendly encouragement.