Re: [DNG] I went back to Openbox
On Fri, Nov 3 2017 at 15:56:28 -0400 Steve Litt wrote: [...] > And unlike ctwm, Openbox is already represented by a Devuan package. Actually I can see a ctwm package in Ascii: $ apt-cache policy ctwm ctwm: Installed: (none) Candidate: 3.7-4+b1 Version table: 3.7-4+b1 500 500 https://pkgmaster.devuan.org/merged ascii/main amd64 Packages Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
On Fri, 3 Nov 2017 at 20:58:24 +0100 Edward Bartolo wrote: > I know little about this Hurd 'little' thing, but it gives me the > shivers like systemd. Similar to the latter, there is a small core at > the centre with all the other helper executables intercommunicating. > Sounds too complicated to get the added advantage, of having a very > minimal kernel running with root privileges, while all other helper > executables that do not need root privileges, run with a lesser > priviledge. > > If I am remember well, MS Windows (the operating system) does have a > micro-kernel, but is it more efficient with an extra layer of > intercommunication? A microkernel architecture makes it easier replacing one of it's peripheral modules or even the core with another one, which is a boon for people wishing to customise their OS down to the guts. A big, monolithic kernel is more difficult to change, as an even small change in a place could entail adjustments in several other places with unexpected results. Hurd is the extension to the kernel of the Unix principle: "have several small components do specific, simple tasks and combine them together to perform complex tasks." On the other hand, microkernel architectures make intercommunication of it's peripheral components between themselves and the core more difficult to synchronise and attune for best efficiency and to avoid bottlenecks and stalemates. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
> I.E. more "modern" than Unix. > > Being "modern" is not always a good thing. I'd have assumed that > wasn't a controversial idea around here. > You are talking sense, yes modern is very often bad alas... > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
On 03/11/17 20:58, Edward Bartolo wrote: I know little about this Hurd 'little' thing, but it gives me the shivers like systemd. Ah. "I know little about it but I don't like it". Similar to the latter, there is a small core at the centre with all the other helper executables intercommunicating. What? I thought the criticism of systemd was that it was monolithic and it's "core" was too large! Sounds too complicated to get the added advantage, of having a very minimal kernel running with root privileges, while all other helper executables that do not need root privileges, run with a lesser priviledge. Huh? Are you against the idea or the implementation? If I am remember well, MS Windows (the operating system) does have a micro-kernel, but is it more efficient with an extra layer of intercommunication? In general the idea with microkernels is security and reliability, not performance -- microkernel boosters will generally handwave and claim the inefficiency is worth it and small anyway. Before writing them off as fools don't forget that MacOS/iOS uses a microkernel (famously one of the biggest/slowest). I will stay with Linux, even though it is a huge monolithic executable. Like systemd? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
On 03/11/17 21:08, J. Fahrner wrote: Windows NT is based on DEC VMS, not a very modern OS ;-) I.E. more "modern" than Unix. Being "modern" is not always a good thing. I'd have assumed that wasn't a controversial idea around here. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
Quoting Steve Litt (sl...@troubleshooters.com): > > I sometimes have Richard Stallman as a house guest, > > Walk on egg shells much? Seriously, Richard Stallman is a gracious and pleasant guest. He's also extremely funny. I was at a Chinese restaurant with him once, and decided to try to yank his chain: 'Richand, I hope you don't take offence that I'm a vi user.' (He'd seen me doing split-screen editing and was wondering if that was an Emacs configuration; I took some small delight in revealing that it was vim.) He fired right back with a smile: 'We of the Church of Emacs don't consider use of vi a sin, but rather penance.' Touché! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
If I am remember well, MS Windows (the operating system) does have a micro-kernel, but is it more efficient with an extra layer of intercommunication? Windows NT is based on DEC VMS, not a very modern OS ;-) https://en.wikipedia.org/wiki/Dave_Cutler Based on VMS, right, like Linux is based on Multics ;) Seriously, efficiency isn't the prime consideration for microkernels. Reliable performance is a better key term. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
Am 2017-11-03 20:58, schrieb Edward Bartolo: If I am remember well, MS Windows (the operating system) does have a micro-kernel, but is it more efficient with an extra layer of intercommunication? Windows NT is based on DEC VMS, not a very modern OS ;-) https://en.wikipedia.org/wiki/Dave_Cutler Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] RMS: was Google abandons UEFI in Chromebooks
I know little about this Hurd 'little' thing, but it gives me the shivers like systemd. Similar to the latter, there is a small core at the centre with all the other helper executables intercommunicating. Sounds too complicated to get the added advantage, of having a very minimal kernel running with root privileges, while all other helper executables that do not need root privileges, run with a lesser priviledge. If I am remember well, MS Windows (the operating system) does have a micro-kernel, but is it more efficient with an extra layer of intercommunication? I will stay with Linux, even though it is a huge monolithic executable. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] I went back to Openbox
Hi all, As many of you remember, I spent a significant chunk of time delving into ctwm: An ultra-configurable and ultra-small-resource WMDE. I've used it, in a stable configuration, on my Daily Driver Desktop (DDD) for well over a month now. During that month, I found some ctwm idiosyncracies continued to confound and annoy me even after a solid month of use. Most of these annoyances fall into one of three categories: 1) Window placement 2) Focus 3) Alt+Tab functionality WINDOW PLACEMENT: The windows often open partially off the screen, or the wrong size. As a result, I have to reach for a mouse all too often, and that's bad for productivity. FOCUS: On Win9x, KDE, Openbox, Xfce, and most other widely accepted WMDEs, Focus means both on-top and receiving keystrokes, unless you've taken extraordinary steps like declaring a window always on top. On ctwm the properties of on-top and receives-keystrokes are independent, making for some strange situations, especially when using ctwm sans-mouse as I do. I often have to revert to a mouse or hit one or more extra key-combos to get the complete focus users of win9x like WMDEs, xfce, KDE and Openbox expect and take for granted. ALT+TAB FUNCTIONALITY There are two different window organization methods: Ring and stack. In a ring configuration, to transition from one window to another on a given workspace, you keep going forward (or backward) through the circle til you get to the desired window. To get back to the original, you go the opposite direction the same number of times. I have hotkeys to go both backward and forward via Alt+Tab and Alt+Grave, and I can tell you even after a couple months of use, I can't move between windows using the sub-brains in my fingers: I have to use the same brain I write and program with. In a stack configuration, the currently focused window is at the top of the stack, with the previous focused window just under it in the stack, on and on until the longest-ago used window is at the bottom of the stack. When a new window gets focus, it goes to the top of the stack. With a stack configuration, you have only one window-switching hotkey: Usually Alt+Tab. Your first Alt+Tab points to the window below the top-stack window. As you keep hitting Tab while holding Alt, it goes lower in the stack, until you release the Alt key, at which time the window at that lower stack point gets focus and gets moved to the top of the stack. One beauty of this is that no matter how many windows, Alt+Tab followed by a release of Alt brings up the previous focused window, enabling you to toggle between just two. This is useful in a wide variety of situations. Moreover, even stuff two and three windows down is eventually learnable by muscle memory, whereas with ring configurations it never becomes that subconscious. So ctwm already has an Alt+Tab deficit, and worse yet, while you're Alt+Tabbing with your thumb still on Alt, ctwm gives no feedback of the window that would focus if you let go at that point. It can become very trial and error and very confusing. But Openbox gives clear, foreground feedback of which window would surface if you lift your fingers off Tab and then Alt. CONCLUSION: Ctwm is an excellent, ultra-configurable WMDE, and properly configured, I highly recommend it. I'll continue to help people with it. But I personally have switched back to Openbox because it better fits with my workflow and productivity methods. I have reason to believe that ctwm is lighter weight than Openbox, but both are so lightweight that only the skimpiest and oldest systems would showcase the difference between their weights. And unlike ctwm, Openbox is already represented by a Devuan package. SteveT Steve Litt October 2017 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] RMS: was Google abandons UEFI in Chromebooks
On Thu, 2 Nov 2017 22:25:58 -0700 Rick Moen wrote: > I sometimes have Richard Stallman as a house guest, Walk on egg shells much? Next time he's at your house, recite the following sentence: "Richard, I'm so glad you contributed all your user utilities to the Linux operating system so I can use Linux on all my Androids. Why don't you make Hurd more efficient so Google will put it on the Android?" I'm kidding, I'm kidding, I'm kidding! SteveT Steve Litt October 2017 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
On Fri, 3 Nov 2017 at 17:15:02 +0100 Alessandro Selli wrote: > On Fri, 3 Nov 2017 at 00:54:44 -0400 > "taii...@gmx.com" wrote: [...] >> there isn't anything special about their laptops that justifies the $2K >> price tag Besides, just to futher prove how little you are to be trusted, this is not the first time you write this blatant lie about the cost of a Puri.sm top-of-the-line laptop: https://puri.sm/shop/librem-15/ Librem 15 $1,599.00 This is a secondary matter compared to people's freedom and privacy, of course, but it's worth pointing out who's doing the lying. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
On Fri, 3 Nov 2017 at 00:52:30 -0400 "taii...@gmx.com" wrote: > In the interest of not starting a big argument again this will by my > last reply on this thread. > > On 11/02/2017 01:14 PM, Alessandro Selli wrote: > >>They are fully worth it. > Certainly not for the price they are charging, for $2K one could buy 5 > Lenovo G505S laptops which are owner controlled with no ME/PSP, an open > source init process (no FSP) or hardware code signing enforcement. They certainly are worth it as ME is fully and demonstrably disabled on their systems and it taked about a dozen Lenovo G505S to sustain the workload a 6th gen i7 does. >> «the LibreM contains a proprietary BIOS» >> >>Wrong. I already wrote about it but I see your pathological hate for >> anything other than Talos/IBM is just too strong, facts cannot stop you >> from spreading lies: > I don't like IBM, but I accept that POWER is the best option and their > marketing of it is honest. And what do the personal tastes of an unknown person prove? > I don't like purism and will never support them until they change their > marketing to be actually honest and stop pretending that they can make > free an intel CPU some vague time in the future. They are not pretending, they proved their point. You're free do prove your own on a technical basis. >> https://puri.sm/faq/ >> >> Technical & Advanced >> Can I buy a Librem with a proprietary BIOS/UEFI? >> >> No. We ship with the free software firmware coreboot. We don’t ship >> Librem 13 or Librem 15 with any proprietary BIOS/UEFI. > It isn't libre and it isn't free software as the hardware and memory > init process is entirely done by Intel's FSP binary blob. No, the signature check of the bootloader is, nothing else. Read nefooce commenting out of ignorance: https://puri.sm/posts/deep-dive-into-intel-me-disablement/ When the ME is disabled using the “HAP” method (thanks to the Positive Technologies for discovering this trick), however, it doesn’t throw an error “because it can’t load a module”: it actually stops itself in a graceful manner, by design. The two approaches are similar in that they both stop the execution of the ME during the hardware initialization (BUP) phase, but with the ME disabled through the HAP method, the ME stops on its own, without putting up a fight, potentially disabling things that the forceful “me_cleaner” approach, with the “unexpected error” state, wouldn’t have disabled. The PCI interface for example, is entirely unable to communicate with the ME processor, and the status of the ME is not even retrievable. So, again, I urge you to stop spreading deliberate lies and misinformation. > They call their laptops the "LibreM" - what is libre about them? > > Fail to include the ME firmware binary in the firmware and your purism > laptop will shut down in 30 minutes "disabled" It does not, read the docs before^Winstead of belching out you ignorance. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
On Fri, 3 Nov 2017 at 00:54:44 -0400 "taii...@gmx.com" wrote: > On 11/02/2017 09:47 PM, Alessandro Selli wrote: > >>Yes, I know, they failed disabling ME and they stopped even trying. > Their website/marketing says that it is "disabled" when it isn't. Yes, it is, and it is verifiable and repeatable: https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/ The Librem 13 and Librem 15 products can be purchased today and will arrive with the Management Engine disabled by default, and it can be verified to be disabled with the source code released to confirm the disablement is accurate. Showing “ME: FW Partition Table : BAD; ME: Bringup Loader Failure : YES” Of course you could prove their claim false and sink them. This is you golden opportunity to do away with their competition, do it! >>Purism >> has gone farther than anyone though possible just two years ago > They didn't make ME_cleaner or contribute to its development at all FYI, I never made that claim, in fact I wrote (if only would you do some reading from time to time): From: Alessandro Selli To: dng@lists.dyne.org Message-ID: <20171103024713.68feecc1@ayu.localdomain> Where did you read anything about intel_me cleaner in https://puri.sm/posts/deep-dive-into-intel-me-disablement/ ? You're stuck with old news. > there isn't anything special about their laptops that justifies the $2K > price tag There is much more than justifies a desktop produced by no-one knows whom that promises to deliver a free system after people will have turned out $4,750.00 for their basic system based on pure faith and no documentation, no blueprints, no insight into their dealings of any nature. > If one insists on a new intel laptop and doesn't mind a blobbed/ME'd > coreboot there are a variety of much less expensive options that support > me cleaner. People do mind, that's the reason they could fully disable it and that's the reason they gained the trust of thousand of customers for their present and future products. Most of what in the past was proprietary and closed-sourced is today at least usable on libre software because people took the heavy task of reverse-engineering it to produce a workable free version. The job is tought and always takes a long time, but those who do it are worthy people working for freedom, those who are today doing this work on Intel chipsets and CPUs are just as worthy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
On Thu, 2 Nov 2017 at 22:26:02 -0400 zap wrote: > >> Coreboot does load blobs for certain devices, so it shouldn't be any > >> surprise that coreboot supports librem. > > They did not lie about this. > Hmm... Doesn't it seem odd though that they call themselves purism and > haven't fully removed the intel ME stuff...? Is this all the proof you can produce to support you silly claims that they lied? Such a poor expoit on your side. > I dunno, it just seems fishy to me. IF you really think I am being > judgmental, ask the people on the trisquel forums... they go even > further to say that they are lying scum bags who only have interest in > money and no interest in freedom. I still cannot see any proof. Since all you can do is repeat other people's smear campaigns, you evidently do not have anything worth spending a second considering. > Me personally? Well I think they have some shady dealings but I do hope > someday they get honest about some of the stuff they hid. If they do > that, and clean up their act and succeed in cleaning everything up, then > I will support them easily. Again, allegations, smears, and no facts, nothing at all. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
On 11/03/2017 04:27 AM, Narcis Garcia wrote: > Please shutdown this giant thread completely. > I'm near to unsubscribe from list. > Most of subjects you are chattering can be found with web browsing. > Devuan project is very fragile with this behaviour. > Very well, If it will help, this will be the last time I reply, given the nature of where the topic is headed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
On November 3, 2017 11:27:21 AM GMT+03:00, Narcis Garcia wrote: >Please shutdown this giant thread completely. >I'm near to unsubscribe from list. >Most of subjects you are chattering can be found with web browsing. >Devuan project is very fragile with this behaviour. Allow me to remind you that this mailing isn't purely for Devuan discussion, dev1galaxy is a place for that. Also, this thread is largely related to Devuan, because UEFI usually makes it harder (or prevents) installing GNU distributions such as Devuan, and if a company like Google is abandoning UEFI this might be good news. Also, the threads don't have to be completely on-topic. Internet is not serious business. If you really don't like a discussion filter it or killfile the senders. You have the technology. --- :^) --- :^) --- :^) --- :^) --- :^) --- :^) --- :^) --- :^) --- https://nextchan.org - https://gitgud.io/m712/blazechan I am awake between 7AM-12AM UTC, hit me up if something's wrong signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Alsa wasn't working on Raspi3 running Devuan Ascii
So, just for anyone hitting this issue in the future, add this to /etc/rc.local ; chgrp audio /dev/snd/* > chmod g+rw /dev/snd/* Not sure why they aren't like that by default :) -- buZz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
Please shutdown this giant thread completely. I'm near to unsubscribe from list. Most of subjects you are chattering can be found with web browsing. Devuan project is very fragile with this behaviour. El 03/11/17 a les 06:25, Rick Moen ha escrit: > I wrote: > >> As it happens, as I mentioned, I just recently bought (to play with) a >> reconditioned Zotac CI321 w/4GB RAM and a 64GB SSD for US $125 with 1 >> year warranty from Zotac after John Franklin mentioned the Zotac >> C-series here. (TY, John!) It has the Intel ME and Intel FSM problems, >> too. > [...] >> The FSP is a separate problem (for both the Purism laptops and my >> little toy Zotac), and I can't say much about more about that. > > I'll do that now. > > Long ago, I had a Lucent Silver Wavelan PCMCIA 802.11b wireless card for > my laptops. At the time, this was the most universally best supported > wireless chipset ever, using the orinoco_cs driver starting with the > 2.4.3 Linux kernel. Like all NICs of that generation, the card had a > built-in ROM that hooked into hardware initialisation. > > Newer cards (and motherboard chipsets) have often had hauntingly similar > functionality to my old 802.11b card, but relegated the ROM > initialisation to a binary-only firmware BLOB that must be hurled into > RAM during hardware recognition -- a change made, as far as I can tell, > just to save a trivial amount of money on ROM costs. It occurred to me > that the functionality of the new BLOBs and of my old Lucent card's ROM > contents was the same. In a few cases, the new BLOBs might even be > exactly the same code, just dd'd to a file from what was formerly burned > into a ROM. > > I sometimes have Richard Stallman as a house guest, and I don't _think_ > I've yet raised this with him, but I keep intending to. So, here's my > attempt to imagine the conversation: > > RM: Here's my point: Why are the firmware BLOBs a software freedom > issue, and the Lucent ROM was not? > > RMS: We at FSF seek freedom to modify in all general-use software, and > the BLOBs, if they were freed, could give developers ability to > improve them, the ability to ensure that they are > freedom-protecting, and the ability to adapt that code to other > purposes for everyone's benefit. > > RM: Sure, but why wasn't that by the same token an issue for the > Lucent ROM code? And, for that matter, why not CPU microcode? > > RMS: Because those are hardware, and you can't change them. Maybe > one day we'll have full visibility into microcode, but one fight > at a time. > > RM: Fair enough, but are you saying that FSF would have no problem > with BLOB firmware images if they get burned into ROMs? I'm > not clear on why that would matter. It's the same code doing > the same functionality. Also, I'm not sure the ROM code in > a Lucent Silver could not be changed. Often, these aren't > classic burn-once ROMs but rather EEPROMs. > > RMS: [here, I run out of imagination] > > The Stallman in my head _might_ have countered that, well, the frontiers > of free software (I almost said 'open source') change over time > depending on what is feasible. Back then, hardware init 'feature' ROMs > were black boxes and we couldn't reasonably dream of changing that. > Now, we may have many obstacles, but we can aspire. > > Angling back to the Intel Firmware Support Package: In 1997, it never > would have even occurred to you to object to the (then-current analogue > of the) Intel FSM as a free software issue, because you'd just call it > 'the feature ROMs', and it was just an unavoidable black-box feature of > your computer, like the CPU microcode. Twenty years later, a bunch of > people see that as an intolerable affront to freedom-respecting hardware > design, even though nothing has actually changed. > > But if that's not a grey area, then I don't know my greyscales. > > (In fairness, Libreboot Project clarifies on > https://libreboot.org/faq.html#intel that the FSP handles System > Management Mode, which raises a genuine security concern, in addition to > doing 1997-style hardware initialisation. To quote my favourite line > from 'The West Wing', 'Ah, the rare valid point.') > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
