Yet another pointless discussion thread...

Talk about anything you feel like talking about. Pull up a soapbox and pontificate to your heart's content. May contain some adult humour or otherwise objectionable content (NSFW). No warez, pr0n or illegal stuff.

Yet another pointless discussion thread...

Postby Head_on_a_Stick » November 4th, 2018, 7:25 am

Randicus Draco Albus wrote:Debian's commitment is little more than lip service.

I would disagree strongly with this statement, Debian's commitment to the GPL is one of the reasons why I use it.

The only non-free packages that I need are firmware for my CPU and wireless card and the most important point about firmware is that every single component on the motherboard of my computer is running on non-free firmware but only the wireless card & CPU load the firmware from Debian — all of the other components have non-free firmware inserted at the factory.

So it could be argued that both Debian and Dragora's refusal to ship the non-free firmware in their official repositories is too extreme and OpenBSD's approach (whereby the non-free firmware is downloaded and installed automatically if the hardware needs it) is far more pragmatic.

Randicus Draco Albus wrote:Apparently the installer now includes the option of enabling said repository during installation.

Yes, and I disapprove :x
Last edited by Head_on_a_Stick on November 7th, 2018, 7:18 pm, edited 3 times in total.
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

Re: another distro: dragora

Postby cynwulf » November 5th, 2018, 11:24 am

Head_on_a_Stick wrote:I would disagree strongly with this statement, Debian's commitment to the GPL is one of the reasons why I use it.

Debian has no specific "commitment to the GPL": https://www.debian.org/social_contract#guidelines

Head_on_a_Stick wrote:So it could be argued that both Debian and Dragora's refusal to ship the non-free firmware in their official repositories is too extreme and OpenBSD's approach (whereby the non-free firmware is downloaded and installed automatically if the hardware needs it) is far more pragmatic.

The Linux kernel firmware was provided until the squeeze release. At that point it was split into packages which were placed in either main or non-free, dependent on licence.

Debian does not distinguish between BLOBs, device microcode/firmware or proprietary programmes. All of these are in the same non-free repository.

Debian hosts the non-free and contrib repositories, Debian maintainers package the non-free software, Debian provides the means to install them and they are packaged and integrated in such a way as to be indistinguishable from the "free" DFSG compliant packages in the main repository.
Head_on_a_Stick wrote:Yes, and I disapprove :x

Yet you "disagree strongly" with the "lip service" statement?

We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created contrib and non-free areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian.

The GNU take on this: https://www.gnu.org/distros/common-distros.html

However, Debian also provides a repository of nonfree software. According to the project, this software is “not part of the Debian system,” but the repository is hosted on many of the project's main servers

I have to agree with GNU/FSF on this one. You can't host and seamlessly integrate stuff, make it freely available and at the same time deny that it's part of the distribution.

"Lip service" is actually being too kind... Debian has been doing this for years and over time has integrated them more and more - especially with regards to the proprietary AMD and Nvidia X BLOBs and added more non-free packages.

The removal and splitting of the firmware is the very definition of tokenism. It benefits no one and is just completely pointless, especially while they maintain a repository for the BLOBs and other proprietary software.
User avatar
cynwulf
 
Posts: 2535
Joined: April 26th, 2011, 2:46 pm

Re: another distro: dragora

Postby nodir » November 5th, 2018, 12:44 pm

cynwulf wrote:Debian hosts the non-free and contrib repositories, Debian maintainers package the non-free software, Debian provides the means to install them and they are packaged and integrated in such a way as to be indistinguishable from the "free" DFSG compliant packages in the main repository.

Well said, and you could go on with that list, if you wanted
(typical forum or IRC experience is: "how do i install icewm?" answer: "did you enable the contrib and non-free repos yet?")
All that is fine and make sense. Only it doesn't make debian a really free distro (one might say: i don't care, all i want is conenience. That is fine too. But it doesn't change the facts how that community handles that issue).

-
Like usual head-on-a-stick thinks more about "how can it be done", then about "does it make sense".
Who on earth would come up with the idea to install a free distribution and then add non-free packages? There are hundreds of linux distos which already do that.

-----------------------------
- big switch of subject -
The other day i spoke with the dude of dragora, about creating recipes and compiling and such and the needed tools (like git and such, which doesn't come up immediatly, but you need quite a few tools to make the workflow fluent). I said "I learnt quite a bit. It sure is fun". He said: "That's what dragora is about."
So anyone looking for something like that, a different approach, it might be an idea. To anyone looking for a working comfortable distro, it probably isn't the right thing. I sure would never have thought that i would consider a modern terminal-emulator to be quite a problem to install ... to give an example.
I used both, gentoe and slackbuilds. Both didn't fell much like building packages from source to me. Which, of course, is a good thing if you want a working and comfortable environment.
nodir
 
Posts: 305
Joined: June 16th, 2015, 10:10 pm

Re: another distro: dragora

Postby cynwulf » November 5th, 2018, 2:08 pm

With Debian non-free, there should at least have been some definition between the non free software and the firmware which is provided with the Linux kernel.

HS is correct, in a round about way, with regards to the firmware. It's specifically a hardware problem. If you have an x86 PC, you already have at least a CPU, network controller, hard disk drive(s), optical drive(s) which are loaded with firmware - plus the (U)EFI / BIOS on the motherboard.

This kind of hardware was designed for MS Windows, it was expected that certain devices would have firmware loaded when the device starts up, rather than coming with it already loaded on a flash ROM. The firmware runs on the device itself, it's not even executable by the host OS.

This is why the Debian approach is silly - you need the firmware for the hardware to work. Your hardware already contains this kind of firmware. It would make more sense for someone to just not use that hardware at all if they care that much about proprietary firmware........

And the situation with the ARM chips and their devices is not much better - the only solution to this is "open hardware".
User avatar
cynwulf
 
Posts: 2535
Joined: April 26th, 2011, 2:46 pm

Re: another distro: dragora

Postby Head_on_a_Stick » November 5th, 2018, 11:02 pm

cynwulf wrote:
Head_on_a_Stick wrote:I would disagree strongly with this statement, Debian's commitment to the GPL is one of the reasons why I use it.

Debian has no specific "commitment to the GPL": https://www.debian.org/social_contract#guidelines

Oh yes, of course, their Free Software Guidelines allow evil licences as well, how silly of me :oops:

Nevertheless, the Social Contract is a beautiful thing, I love it dearly.

cymwulf wrote:Debian does not distinguish between BLOBs, device microcode/firmware or proprietary programmes. All of these are in the same non-free repository.

So what? Neither the firmware or the software has the source code available, that's the important point, surely?

Do we really need more components in the repositories? I think not.

cymwulf wrote:Debian hosts the non-free and contrib repositories, Debian maintainers package the non-free software, Debian provides the means to install them

Again: so what?

I appreciate the choice and the Social Contract complies Debian to support the user whatever their choice may be:
Our priorities are our users and free software

We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

^ I like that :)

cymwulf wrote:
Head_on_a_Stick wrote:Yes, and I disapprove :x

Yet you "disagree strongly" with the "lip service" statement?

Yes.

Pragmatism over-rules principles (for me at least) and have you ever tried getting the NVIDIA blobs working in an Optimus laptop? :mrgreen:

cymwulf wrote:"Lip service" is actually being too kind... Debian has been doing this for years and over time has integrated them more and more - especially with regards to the proprietary AMD and Nvidia X BLOBs and added more non-free packages.

Er, no, the NVIDIA blobs are still complete bastards under Debian (and rightly so) and AMD have gone open source:

https://packages.debian.org/stretch/xse ... deo-amdgpu

Please don't post FUD.

cymwulf wrote:The removal and splitting of the firmware is the very definition of tokenism. It benefits no one and is just completely pointless

I really appreciate being able to remove all the firmware I don't need and a de-blobbed kernel is also a big plus for me (and arguably a security advantage).
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

Re: another distro: dragora

Postby nodir » November 6th, 2018, 12:23 am

debian is an old african word for ...
nodir
 
Posts: 305
Joined: June 16th, 2015, 10:10 pm

Re: another distro: dragora

Postby Randicus Draco Albus » November 6th, 2018, 3:23 am

Pragmatism over-rules principles
:lol:
Klingons are fun, but Romulans are the sexiest women in the galaxy.
User avatar
Randicus Draco Albus
 
Posts: 1496
Joined: September 22nd, 2011, 1:22 pm

Re: another distro: dragora

Postby cynwulf » November 6th, 2018, 9:55 am

Head_on_a_Stick wrote:Oh yes, of course, their Free Software Guidelines allow evil licences as well, how silly of me :oops:

Your continual references to "evil licences" isn't clever.
Head_on_a_Stick wrote:So what? [blah, blah, blah]

You appear to have reading comprehension problems.
Head_on_a_Stick wrote:AMD have gone open source:

https://packages.debian.org/stretch/xse ... deo-amdgpu

Please don't post FUD.

Please research properly before you attempt to correct others:

https://packages.debian.org/stretch/fir ... d-graphics
https://support.amd.com/en-us/kb-articl ... eta-Driver–Release-Notes.aspx

Do you seriously believe that the likes of AMD would open source their proprietary core technologies...?
Head_on_a_Stick wrote:I really appreciate being able to remove all the firmware I don't need and a de-blobbed kernel is also a big plus for me (and arguably a security advantage).

Despite your earlier comments on this subject, you've clearly been suckered. As with many Linux fans, you fail to differentiate between device microcode and a proprietary BLOB in the form of a LKM. I assumed from your earlier post that you had at least half a clue, but it would appear not.

If you want to believe that a lot of firmware (not BLOBs) which will never be loaded, used or executed if you don't have the corresponding hardware, is magically going to spring into life and become a security concern, just by sitting there taking up a few MB, that's entirely up to you... but it's also the very definition of "FUD".
User avatar
cynwulf
 
Posts: 2535
Joined: April 26th, 2011, 2:46 pm

Re: another distro: dragora

Postby nodir » November 6th, 2018, 11:33 am

It get's way worse if you combine different threads:
"i don't know the debian-installer well, as i mainly do debootstrap installations"
" 'chroot' <- "Are you refering to a jail?".

Just random words, picked up somewhere. nothing has any meaning. Pragmatism (aka: what the fuck do i care what i said just five minutes ago?)
nodir
 
Posts: 305
Joined: June 16th, 2015, 10:10 pm

Re: another distro: dragora

Postby cynwulf » November 6th, 2018, 4:49 pm

Funnily enough, I was just reading up on the latest Intel SMT mess. I was out of the loop at the weekend so hadn't seen this (found via FreeBSD forums thread):

https://www.theregister.co.uk/2018/11/0 ... ty_attack/

A bit more searching led me to FDN!

And HS has a thread on this there: http://forums.debian.net/viewtopic.php?f=16&t=138972

I have to say that while those elaborate and very involved methods (which so far don't seem to have worked?) may be solutions for some in certain cases (i.e. where there is no access to the BIOS or where no control for SMT is present), you have not mentioned at all, as to whether you've attempted to simply disable SMT in the BIOS/(U)EFI? Surely this is the best and first suggestion?

As suggested here in fact, by Theo de Raadt:
https://marc.info/?l=openbsd-tech&m=153504937925732
DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS.

So please try take responsibility for your own machines: Disable SMT in
the BIOS menu
, and upgrade your BIOS if you can.


And: https://seclists.org/oss-sec/2018/q4/123
## Fix

Disable SMT/Hyper-Threading in the bios


I suppose just putting that in your thread, does not a very interesting thread make (plus no decent excuse to post a typically overly complex systemd specific solution), but surely it could have featured somewhere...?

Just manually disabling odd numbered cores, as I've also seen suggested on various sites, seems like a poor solution - it's a messy workaround at best - I've seen this proposed elsewhere as well. So far as I can tell, there is no kernel configuration option to disable it. Short of killing SMP support altogether, which will also kill SMT as a side effect and give you a nice uniprocessor kernel.

The only robust solution for OS' which have not disabled SMT as standard, is to prevent the OS from "seeing" the SMT cores - and that has to be a BIOS setting.
User avatar
cynwulf
 
Posts: 2535
Joined: April 26th, 2011, 2:46 pm

Next

Return to Nonsense

Who is online

Users browsing this forum: No registered users and 1 guest

cron

x