Re: [DNG] Installer images for armel, armhf and ppc64 need testing
On 3/2/20 7:54 PM, fsmithred wrote:
> We built beowulf installer images for armel, armhf and ppc64el. If you
> have appropriate hardware, please test and report.
>
> armel (no mini.iso for these. I hope you know what to do.)
> https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer-armel/current/images/
>
> kirkwood/netboot/marvell/{dreamplug,guruplug,sheevaplug,sheevaplug-esata}
> kirkwood/netboot/seagate/dockstar
> orion/netboot/buffalo
>
> armhf
> https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer-armhf/current/images/netboot/mini.iso
>
> ppc64el
> https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer-ppc64el/current/images/netboot/mini.iso
>
> Thanks,
> fsmithred
>
I installed from the ppc64el mini.iso in qemu today. That one works.
Anyone else?
fsr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why is polkit needed?
On Fri, Mar 6, 2020, at 12:51 PM, Hendrik Boom wrote: > On Thu, Mar 05, 2020 at 02:09:37PM +0100, Didier Kryn wrote: > > Le 03/03/2020 à 23:37, tekHedd a écrit : > > > > > > So, I would consider rewriting polkit and dbus from scratch. > > > > > > Also, who has time to rewrite polkit and dbus from scratch? > > What are the actual requirements for a dbus-like system? Requirements > that would allow a completely different design? Exactly. Are there even requirements supporting the current design? Were there ever requirements at all? We can easily see what it does, but it's really hard to determine what it *needs* to do. Bad sign: You know you've chosen poorly the moment you are simultaneously offering a) broadcast messaging and b) guaranteed delivery. A google search for d-bus requirements turns up, well, documentation of its current architecture. No requirements. Also contains this choice quote: "The usage of D-Bus is steadily expanding beyond the initial scope of desktop environments to cover an increasing amount of system services. For instance, NetworkManager network daemon, BlueZ bluetooth stack and Pulseaudio sound server use D-Bus to provide part or all of its services. systemd uses the D-Bus wire protocol for communication between systemctl and systemd, and is also promoting traditional system daemons to D-Bus services, such as logind.[25] Another heavy user of D-Bus is Polkit, whose policy authority daemon is implemented as a service connected to the system bus.[26]" So... all of the usual suspects. What is absent here? That's right, no *other* programs are listed besides the usual suspects. So who really uses it? Nothing I can find suggests that dbus is used for anything essential, besides possibly polkit. And there's nothing suggesting that polkit needs to be implemented via dbus. Therefore, you could eliminate dbus entirely and rethink polkit's implementation without undue impact, assuming you are ditching systemd and friends of course. (I realize I'm skirting "devil's advocate" territory here...) t ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF now defaults to DNS-over-HTTPS for US
Steve Litt writes:
> goli...@devuan.org wrote:
>
>> Just great! So how can we keep off this cloudflare thing?
>>
>> https://www.theregister.co.uk/2020/02/25/mozilla_turns_on_dns_over_https_by_default_for_usa/
>
> "Another relevant question is whether further centralisation [SIC] of
> the internet is, inherently, a bad thing."
This is a wrong question based on a false dichotomy in this article. It
assumes users will always have to use some recursive resolver operated
by some third party, hence, they can only chose between
a) use the servers you got assigned in some environment "which may
include public WiFi" ("Run your life!")
b) use some "trusted DoH provider" (trusted by some other US company to
be good enough for its users, that is)
IOW, that uses will always have to provide a complete history of all
their "web movement" to someone.
But this is not the case. There's nothing which stops users from running
their own, fully capable resolver locally[*] (or somewhere on a local
network) and thus, not make a comprehensive browsing history available
to any third party.
And DoH prevents that. That Google (AFAIK) invented this is certainly
just coincidence.
[*] Except systemd-resolvd, of course, at that's (reportedly) a stub
resolver to replace another stub resolver :->.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why is polkit needed?
On Thu, Mar 05, 2020 at 02:09:37PM +0100, Didier Kryn wrote: > Le 03/03/2020 à 23:37, tekHedd a écrit : > > > > So, I would consider rewriting polkit and dbus from scratch. > > > > Also, who has time to rewrite polkit and dbus from scratch? What are the actual requirements for a dbus-like system? Requirements that would allow a completely different design? > > * dbus probably not salvageable, also deeply integrated into every > > possible program; consider dbus compatibility shim D: > By definition, a shim preserves the API, and I consider the problem of > Dbus is precisely its API. Preserving the API would not be done by the new system; the shim is to allow old software to continue running until it was rewritten. (And yes, I know there's nothing so permanent as a temporary building.) -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why is polkit needed?
On Wed, Mar 4, 2020, at 9:42 PM, Rick Moen wrote: > Quoting tekHedd (tekh...@byteheaven.net): > > > Re this thread, clearly a multi-user system with a GUI does need > > polkit and /some/ sort of dbus mechanism (which I will henceforth > > refer to as the "dbus mechanism" as if it were some sort of doomsday > > device). > > I don't think I buy that assumption, at all. Users who need access to a > sound device can be added to the group with privileges to that sound > advice, etc. Proper user-friendly administrative tools can front-end > that granting of user privilege. A whole new system layer to regulate > access to everything strikes me a solution in search of a problem. Cool software doesn't really happen without the ability for apps to communicate and read/write the state of the system and communicate with other user level components. I maintain that at the core of each of these new annoying packages is genuine user need, combined with poor execution and massive feature creep. And the reason for this: - execution is actually difficult - requirements management is more difficult I think most people on this list would agree that the core requirements could have been/should be solved without creating a configuration nightmare and/or discarding the UNIX paradigm. I maintain that this can be accomplished by isolating the actual requirements that are the reason polkit/dbus are shipped on every system, and separating them from the "other things that these things also do". Mind you, I'm not sure /why/ I care, maybe it's because I like using Linux. :) > dbus as a generic object-and-message-passing mechanism seems per-se > harmless enough, but the history of component software using a messaging > bus (e.g., CORBA, KCOP, Microsoft's OLE) is wretched and wasteful enough DCOM :/ Yeah, dbus is extra sad considering that it came after all that. Message systems can be handy, but I agree: the implementation was (obviously?) not driven by requirements other than that of a developer going "wouldn't it be neat if I made a thing called dbus". My hypothesis is not "dbus is needed" but rather that "projects that use dbus are /sometimes/ driven by a genuine need that is not solved elsewhere". Hmm, perhaps scraping the dbus issue tracker for past feature requirements would confirm or disprove this.. I don't know, maybe it's not a solvable problem. t ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF now defaults to DNS-over-HTTPS for US
On Thu, Mar 5, 2020, at 2:18 PM, Florian Zieboll wrote: > > Which leads to an even deeper question: As we tend to move into the > direction we look (think of learning a header or somersault or perhaps > also of getting through a dangerous situation when driving a vehicle) - > what does this mean for writing dystopia? [2] Fear is a bad adviser. Well, it is said that people who read science fiction are better equipped to cope with new and unexpected situations. But humans are turning out to be very predictable and the situations are not new or unexpected when compared to Orwell. The whole DNS vs DoH problem is another choice of "centralization and trust in authority" vs "decreased safety and trust in entities closer to home". The current trend is authoritarian. Orwell teaches us all about that. :) The current trend in tech puts a lot of power in the hands of the root SSL authorities. t ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
