Re: Mini-DebConf Belo Horizonte (Brazil) 2024: registration and CfP are open
Debian is a brilliant OS; I use it daily on my Raspberry Pi! 😉
Re: Hoping to donate/sell a Talos II motherboard
On Wednesday, March 1, 2023, wrote: > March 1, 2023 5:11 AM, "Toshaan Bharvani | VanTosh" wrote: >> Yes, please, I am interested. >> I would use it for PowerEL, LibreBMC and LibreSOC. >> All open source projects. >> Is this just a board or also a CPU? > > It is just the motherboard. :) so someone has to spend maybe an additional... USD... 1000? 2000? to get it into a useful state. minimum 128 GB preferably a lot more than that (in order to host multiple VMs), plus SSDs / HDDs, plus a minimum 1,000 watt power supply. > donate to the university of Oregon, whose contact is Toshaan Bharvani. ah no. Two SEPARATE options: * donate to University of Oregon, whose contact is Sameer Shende, and if they agree they can add it to the multiple POWER9 systems which are already available to FOSS Groups through the OpenPOWER Hub, have been for a few years now. * donate to Vantosh Ltd, whose contact is Toshaan Bharvani, who already also hosts POWER9 systems for FOSS Projects (Libre-SOC in particular), and who is the maintainer of the PowerEL distribution. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Hoping to donate/sell a Talos II motherboard
On Tuesday, February 28, 2023, wrote: > Hello you fabulous developers! > > My friend has a spare Talos II motherboard that is currently sitting in his house > in Indiana USA collecting dust. > > https://www.raptorcs.com/TALOSII/ > > I have convinced him to donate/sell it to an open source project or developer. > > I reached out to Richard Stallman, and he agreed to take the board. I am certain that the > FSF would put it to good use. My friend and I have not yet decided, to whom we will give > the motherboard. Is it possible that I could give it to someone or project, such that all > parties here would benefit? i am reasonably certain that Toshaan Bharvani would be prepared to do that although he would need to speak for himself. the other option would be to donate it to the University of Oregon who already have POWER9 systems that are accessible to FOSS projects via the "OpenPOWER Hub". cc'ing Sameer as well. (in case that wasn't clear: FOSS projects can *already*, right now, apply for access to POWER9 systems, do i have that right, Sameer?) > Is there any project or developer here that would be willing to take this motherboard and create > virtual machines that other projects could have access to? > > Thoughts? > > Thanks, > > Joshua Branson > FOSS enthusiast > https://gnucode.me > > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Re: Concerns about Security of packages in Debain OS and the Operating system itself.
> Do you have a publication of that analysis? I was thinking the same > about the organization of Debian for some time but never did analysis > or compared it to other distros. i found it here http://lkcl.net/reports/wot/ it's dated 2017 (not a bad guess, 4 years). please bear in mind, the primary reason for writing it was to help a group that was (still is) severely lacking in both technical security understanding and also infrastructure within their distro. as a group they genuinely believed that SSL would be beneficial in some way. a leading gnunet developer on the list made one single comment and then, knowing that the size of the group was large and comprised largely non-security-conscious individuals, knew that any further discussion would be... unwise, declined to take part further. naively, i tried my best to explain it (hence this document - which contains a detailed appendix outlining why SSL is dangerous as it was the primary focus of bikeshedded "but it'll add an extra layer of security") i was intending to document the examples of other Distros, but the bikeshedding degenerated into verbally-abusive behaviour and i was so shocked that i terminated further planned development of the document (and left the group). this has left some of the thoughts which i outlined in my post unpublished. the general idea was - and i would welcome contributions here (http://lkcl.net/reports/wot/wot.tex - also see Makefile in the same dir) the general idea was to add example Distros, explaining where they break down, because they break one (or more) of the chain of integrity, referring clearly to the "Requirement" as a way to do so. (and then clarifying the requirements further, in an iterative process) for example Ubuntu violates at least Requirement 11, because the size of the group comprising the ring-of-trust is too small, and the integrity of the group is compromised because they may be threatened with salary reductions or loss of employment if they don't do what the Corporation demands. it sounds obvious once expressed, but i can guarantee that it's not even remotely on the radar of the average ubuntu user. i do have to say that having a public document like this would go a long way towards preventing some of the criticism that Debian receives for "being slow to react" and "being too complex" or "not secure enough" i've had discussions with NixOS developers recently, who genuinely believe that Debian is vulnerable and NixOS is better because, their words, "debian doesn't have reproducible builds." rather embarrassingly i had to explain to them that the reason why they're having an easy time of adding reproducible builds to NixOS is because both debian and fedora originally did all the heavy lifting, and have had reproducible builds for what... 8 years now? those distros *paved the way*... oh and then didn't really talk about it or promote it. hence why NixOS developers genuinely believe that they are "the world's first secure reproducible build distro". explaining to them that relying on github and unverified unsigned git checkins is a bad idea (no commits and no packages are GPG-signed in NixOS) took multiple round-trips, spanning over a week. > Also I like to add that reproducible builds are an excellent addition > to the mechanisms you are describing. very true: they'd be part of the integrity-checking, down to the binary level. interestingly (this from my Software Engineering training) it'd be added to the section on Functional Specification, not necessarily Requirements. if added to Requirements it would be worded something like: "Other Maintainers should be able to verify the full integrity of a package by reproducing its contents from the original source" the *implementation* of that - part of the Functional Specification - would mention "reproducible builds" because that is *how* you fulfil the Requirement. i'd be delighted to receive a patch to the .tex file to add that: please do also remember to add an appropriate Copyright notice at the same time, should you choose to contribute. http://lkcl.net/reports/wot/wot.tex best, l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
audacity has become spyware
https://yro.slashdot.org/story/21/07/05/2155212/open-source-audio-editor-audacity-has-become-spyware --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Friday, August 23, 2019, Karsten Merker wrote: > > and decide for themselves who is displaying "violent hatred" on > mailing lists and come to their own judgement about your > allegations: You've now violated the Debian Conduct twice in under an hour. https://www.debian.org/code_of_conduct Karsten: I very deliberately made a conscious choice to respect the debian devel list members by not poisoning the list with an extremely toxic discussion. I note that chose to do so *instead* of saying "ah yes I see your perspective, I see how the rewritten version was much less confrontational, I will try to improve my communication in the future" In other words, your intention, just like Ted's word (where he chose to ignore information - deliberately or unintentionally - that I had provided, and used confrontational language *and you supported him in doing that*, Karsten), is not to work together to resolve matters, it is to inflame them and to poison this conversation. Do you understand that that is what you have done? Please can someone urgently step in and have a private word with Karsten and Ted, I feel that because of their unreasonable approach that they are making me feel extremely unwelcome to contribute further to this discussion. Debian's Code and the matching Diversity Statement are extremely simple: the best tgat I have ever seen. The combined documents request that people assume good faith, that they work together to further the goals of the Debian Project, and that people go out of their way to be inclusive of all who wish to see Debian progress. I trust that these violations are clear and will be taken seriously. With many apologies to everyone else on debian-devel that the conversation has been poisoned by hostile intentions. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Thu, Aug 22, 2019 at 7:58 PM Karsten Merker wrote: > On Fri, Aug 23, 2019 at 01:49:57AM +0800, Luke Kenneth Casson Leighton wrote: > > > The last time that we spoke, Theo, some time around 2003 you informed me > > that you were doing so very deliberately "to show everyone how stupid I > > was". It was on the linux kernel lists. It was also very shockingly > > unkind. I can see some signs that you are tryint to be deliberately > > confrontational and I do not like it. > > > > As the Debian lists are covered by the Debian Conduct document, please read > > it and review the talk that was given in Taipei (it had a panel of 5 people > > including Steve McIntyre, if someone remembers it please do kindly post a > > link). [i found it: https://wiki.debian.org/AntiHarassment ] > Luke, please reconsider what you wrote above. ted has a history of being abusive, and hiding it extremely well. the term is called "intellectual bullying". it's where someone treats someone in a way that, to the majority of people, looks really, *really* reasonable, but on close inspection you find signs that they're not actually trying to work *with* people in the group, towards a solution, they're using the conversation as a way to make themselves superior to another human being. this is a form of "harrassment" - an intellectual kind. > The only person in > this thread whom I perceive as being confrontational is you, > while Ted has in my view been perfectly civil and completely > non-confrontational in what he wrote here. ah, karsten: yes, i recall your violent hatred from very recent conversations on other lists. i did make an effort to present you with an opportunity to use the resources from the conflict resolution network, www.crnhq.org, but i did not receive a response. your response may seem reasonable to you, however you just demonstrated - as you did on the other list - that you are willing to "blame" another person and are willing to *support* others who have engaged in intellectual bullying in the past (Ted Tso), and are actively supportive of his efforts to try that here. just as you were actively supportive of the ongoing recent and persistent intellectual bullying on the other list. i'm therefore contacting the anti-harrassment team, above, to report both you (Karsten), and also Ted Tso. i appreciate that it's normally just for events, however they are the people most likely to be in a position to speak with you, privately, and also to advise on the best course of action. if you had responded on the other list, in a way that demonstrated a willingness to resolve matters and work together, for the benefit of everyone on that list, i would not be reporting you here. if you had responded on *this* list with words to the effect, "did you know, luke, that your words could be viewed as being confrontational? to me, it genuinely looks like Ted is being perfectly civil. could you clarify, as it looks like i have made a mistake in interpreting what you have written? what did i miss?" i would not be reporting you here. can you see the difference between that paragraph, above, and what you wrote? do you notice that the rewritten words do not assume "bad faith"? l.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Thursday, August 22, 2019, Theodore Y. Ts'o wrote: > On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton > wrote: > > > > so i hope that list gives a bit more context as to how serious the > > consequences of dropping 32 bit support really is. > > I very much doubt we are any where near "dropping 32-bit support". Theo you have not rear the context. Sam specifically asked a question and I answered it. > There's a lot of "all or nothing thinking" in your argumentation > style. That would be incorrect, Theo. Having read the Debian Conduct Document, please also read it. Also please review the context properly. As Sam has said multiple times, what's much more likely is that the > set of packages that can't be built on native packages on 32-bit > platforms will grow over time. Yes. Everyone is aware of that. It is why the conversation exists. Why did you assume that I was not aware of this? The question is when will that > actually *matter*? There are many of these packages which no one > would want to run on a 32-bit platform, especially if we're focusing > on the embedded use case. That would also be specifically missing the point, which I have mentioned at least twice, namely that 32 bit Dual and Quad Core 1ghz and above systems are perfectly capable of running a full desktop environment. Obvioudly you don't run video editing or other computationally heavy tasks on them, however many such so-called "embedded" claased processors were specifically designed for Android tablets or IPTV and so consequently not only are 3D capable, they also have 1080p video playback. So again: these are NOT pathetic little SINGLE CORE 8 to 10 year old processors with 256 to 512MB of RAM (OMAP3 series, Allwinner A10), these are 2 to 5 year old DUAL to QUAD Core systems, 2 to 4 GB RAM, 1 to 1.5ghz and perfectly capable of booting to a full Desktop OS in 25 seconds or less. The last time that we spoke, Theo, some time around 2003 you informed me that you were doing so very deliberately "to show everyone how stupid I was". It was on the linux kernel lists. It was also very shockingly unkind. I can see some signs that you are tryint to be deliberately confrontational and I do not like it. As the Debian lists are covered by the Debian Conduct document, please read it and review the talk that was given in Taipei (it had a panel of 5 people including Steve McIntyre, if someone remembers it please do kindly post a link). Thank you. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
i remembered a couple more: * the freescale iMX6 has a 19-year supply / long-term support (with about another 10 years to go). it's used in the bunnie huang "Novena Laptop" and can take up to 4GB of RAM. processor core: *32-bit* ARM Cortex A9, in 1, 2 and 4-core SMP arrangements. * the Zync 7000 series of FPGAs. they're typically supplied with 1GB RAM on developer kits (and sometimes with an SODIMM socket), and are extremely useful and powerful. processor core: *32-bit* Dual-Core ARM Cortex A9 @ 800mhz. these (as well as the other 32-bit SBCs i mentioned, particularly the ones that work with 2GB of RAM) are not "shrinking violets". they're perfectly capable of running a full desktop GUI, Libre Office, web browsers, Gimp - everything that the "average user" needs. the Allwinner A20, Allwinner R40, Freescale iMX6 - these even have SATA on-board! they're more than capable of having a HDD or SSD connected to them, to create a *really* decent low-power desktop system. now, i don't _want_ to say that it's insulting to these systems to relegate them to "embedded" distro status (buildroot and other severely-limited distributions), but i don't know what other phrase to use. "lost opportunity", perhaps? something along those lines. so i hope that list gives a bit more context as to how serious the consequences of dropping 32 bit support really is. l.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Tue, Aug 20, 2019 at 3:31 PM Sam Hartman wrote: > > >>>>> "\Luke" == Luke Kenneth Casson Leighton writes: > Hi. > First, thanks for working with you. > I'm seeing a lot more depth into where you're coming from, and it is > greatly appreciated. likewise. > I'd like to better understand the train wreck you see. that 32-bit hardware is consigned to landfill. debian has a far higher impact (as a leader, due to the number of ports) than i think anyone realises. if debian says "we're dropping 32 bit hardware", that's it, it's done. [btw, i'm still running my web site off of a 2006 dual-core XEON, because it was one of the extremely hard-to-get ultra-low-power ones that, at idle, the entire system only used 4 watts at the plug]. > Eventually, Debian itself will drop 32-bit arches. that's the nightmare trainwreck that i foresee. that means that every person who has an original raspberry pi who wants to run debian... can't. every person who has a $30 to $90 32-bit SBC with a 32-bit ARM core from AMLogic, Rockchip, Allwinner - landfill. marvell openrd ultimate: landfill. the highly efficient dual-core XEON that runs the email and web service that i'm using to communicate: landfill. ingenic's *entire product range* - based as it is on MIPS32 - landfill. that's an entire company's product range that's going to be wiped out because of an *assumption* that all hardware is going "64 bit"! to give you some idea of how influential debian really is: one of *the* most iconic processors that AMD, bless 'em, tried desperately for about a decade to End-of-Life, was the AMD Geode LX800. the reason why it wouldn't die is because up until around 2013, *debian still supported it* out-of-the-box. and the reason why it was so well supported in the first place was: the OLPC project [they still get over 10,000 software downloads a week on the OLPC website, btw - 12 years beyond the expected lifetime of the OLPC XO-1] i installed debian back in 2007 on a First International Computers (FIC) box with an AMD Geode LX800, for Earth University in Costa Rica. over 10 years later they keep phoning up my friend, saying "what the hell kind of voodoo magic did you put in this box?? we've had 10 years worth of failed computers in the library next to this thing, and this damn tiny machine that only uses 5 watts *just won't die*" :) there's absolutely no chance of upgrading it, now. the embedded world is something that people running x86_64 hardware just are... completely unaware of. additionally, the sheer overwhelming package support and convenience of debian makes it the "leader", no matter the "statistics" of other distros. other distros cover one, *maybe* two hardware ports: x86_64, and *maybe* arm64 if we're lucky. if debian gives up, that leaves people who are depending on them _really_ in an extremely bad position. and yes, i'm keenly aware that that's people who *aren't* paying debian developers, nor are they paying the upstream developers. maybe it will be a good thing, if 32-bit hardware support in debian is dropped. it would certainly get peoples' attention that they actually f*g well should start paying software libre developers properly, instead of constantly spongeing off of them, in a way that shellshock and heartbleed really didn't grab people. at least with shellshock, heartbleed etc. there was a software "fix". dropping 32 bit hardware support, there *is* no software fix. l.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Tue, Aug 20, 2019 at 2:52 PM Sam Hartman wrote: > I think my concern about your approach is that you're trying to change > how the entire world thinks. that would be... how can i put it... an "incorrect" interpretation. i think globally - i always have. i didn't start the NT Domains Reverse-Engineering "because it would be fun", i did it because, world-wide, i could see the harm that was being caused by the polarisation between the Windows and UNIX worlds. > You're trying to convince everyone to be > conservative in how much (virtual) memory they use. not quite: i'm inviting people to become *aware of the consequences* of *not* being conservative in how much (virtual) memory they use... when the consequences of their focus on the task that is "today" and is "right now", with "my resources and my development machine" are extended to a global scale. whether people listen or not is up to them. > Except I think that a lot of people actually only do need to care about > 64-bit environments with reasonable memory. I think that will increase > over time. > > I think that approaches that focus the cost of constrained environments > onto places where we need constrained environments are actually better. > > There are cases where it's actually easier to write code assuming you > have lots of virtual memory. yes. a *lot* easier. LMDB for example simply will not work on files that are larger than 4GB, because it uses shared-memory copy-on-write B+-Trees (just like BTRFS). ...oops :) > Human time is one of our most precious > resources. It's reasonable for people to value their own time. Even > when people are aware of the tradeoffs, they may genuinely decide that > being able to write code faster and that is conceptually simpler is the > right choice for them. indeed. i do recognise this. one of the first tasks that i was given at university was to write a Matrix Multiply function that could (hypothetically) extend well beyond the size of virtual memory (let alone physical memory). "vast matrix multiply" is known to be such a hard problem that you just... do... not... try it. you use a math library, and that's really the end of the discussion! there are several other computer science problems that fall into this category. one of them is, ironically (given how the discussion started) linking. i really wish Dr Stallman's algorithms had not been ripped out of ld. > And having a flat address space is often > conceptually simpler than having what amounts to multiple types/levels > of addressing. In this sense, having an on-disk record store/database > and indexing that and having a library to access it is just a complex > addressing mechanism. > > We see this trade off all over the place as memory mapped databases > compete ... such as LMDB... > with more complex relational databases which compete with nosql > databases which compete with sharded cloud databases that are spread > across thousands of nodes. There are trade offs involving complexity of > code, time to write code, latency, overall throughput, consistency, etc. > > How much effort we go to support 32-bit architectures as our datasets > (and building is just another dataset) grow is just the same trade offs > in miniture. And choosing to write code quickly is often the best > answer. It gets us code after all. indeed. i do get it - i did say. i'm aware that software libre developers aren't paid, so it's extremely challenging to expect any change - at all. they're certainly not paid by the manufacturers of the hardware that their software actually *runs* on. i just... it's frustrating for me to think ahead, projecting where things are going (which i do all the time), and see the train wreck that has a high probability of occurring. l.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Tue, Aug 20, 2019 at 1:17 PM Sam Hartman wrote: > I'd ask you to reconsider your argument style. that's very reasonable, and appreciated the way that you put it. > I'm particularly frustrated that you spent your entire reply moralizing > and ignored the technical points I made. ah: i really didn't (apologies for giving that impression). i mentioned that earlier in the thread, cross-building had been mentioned, and (if memory serves correctly), the build team had already said it wasn't something that should be done lightly. > As you point out there are challenges with cross building. yes. openembedded, as one of the longest-standing cross-compiling-capable distros that has been able to target sub-16MB systems as well as modern desktops for two decades, deals with it in a technically amazing way, including: * the option to over-ride autoconf with specially-prepared config.sub / config.guess files * the ability to compile through a command-line-driven hosted native compiler *inside qemu* * many more "tricks" which i barely remember. so i know it can be done... it's just that, historically, the efforts completely overwhelmed the (small) team, as the number of systems, options and flexibility that they had to keep track of far exceeded their resources. > I even agree with you that we cannot address these challenges and get to > a point where we have confidence a large fraction of our software will > cross-build successfully. sigh. > But we don't need to address a large fraction of the source packages. > There are a relatively small fraction of the source packages that > require more than 2G of RAM to build. ... at the moment. with there being a lack of awareness of the consequences of the general thinking, "i have a 64 bit system, everyone else must have a 64 bit system, 32-bit must be on its last legs, therefore i don't need to pay attention to it at all", unless there is a wider (world-wide) general awareness campaign, that number is only going to go up, isn't it? > Especially given that in the cases we care about we can (at least today) > arrange to natively run both host and target binaries, I think we can > approach limited cross-building in ways that meet our needs. > Examples include installing cross-compilers for arm64 targeting arm32 > into the arm32 build chroots when building arm32 on native arm64 > hardware. > There are limitations to that we've discussed in the thread. indeed. and my (limited) torture-testing of ld, showed that it really doesn't work reliably (i.e. there's bugs in binutils that are triggered by large binaries greater than 4GB being linked *on 64-bit systems*). it's a mess. > Yes, there's work to be done with all the above. > My personal belief is that the work I'm talking about is more tractable > than your proposal to significantly change how we think about cross > library linkage. i forgot to say: i'm thinking ahead over the next 3-10 years, projecting the current trends. > And ultimately, if no one does the work, then we will lose the 32-bit > architectures. ... and i have a thousand 32-bit systems that i am delivering on a crowdfunding campaign, the majority of which would go directly into landfill. l.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Mon, Aug 19, 2019 at 7:29 PM Sam Hartman wrote: > Your entire argument is built on the premise that it is actually > desirable for these applications (compilers, linkers, etc) to work in > 32-bit address spaces. that's right [and in another message in the thread it was mentioned that builds have to be done natively. the reasons are to do with mistakes that cross-compiling, particularly during autoconf hardware/feature-detection, can introduce *into the binary*. with 40,000 packages to build, it is just far too much extra work to analyse even a fraction of them] at the beginning of the thread, the very first thing that was mentioned was: is it acceptable for all of us to abdicate responsibility and, "by default" - by failing to take that responsibility - end up indirectly responsible for the destruction and consignment to landfill of otherwise perfectly good [32-bit] hardware? now, if that is something that you - all of you - find to be perfectly acceptable, then please continue to not make the decision to take any action, and come up with whatever justifications you see fit which will help you to ignore the consequences. that's the "tough, reality-as-it-is, in-your-face" way to look at it. the _other_ way to look at is: "nobody's paying any of us to do this, we're perfectly fine doing what we're doing, we're perfectly okay with western resources, we can get nice high-end hardware, i'm doing fine, why should i care??". this perspective was one that i first encountered during a ukuug conference on samba as far back as... 1998. i was too shocked to even answer the question, not least because everybody in the room clapped at this utterly selfish, self-centered "i'm fine, i'm doing my own thing, why should i care, nobody's paying us, so screw microsoft and screw those stupid users for using proprietary software, they get everything they deserve" perspective. this very similar situation - 32-bit hardware being consigned to landfill - is slowly and inexorably coming at us, being squeezed from all sides not just by 32-bit hardware itself being completely useless for actual *development* purposes (who actually still has a 32-bit system as a main development machine?) it's being squeezed out by advances in standards, processor speed, user expectations and much more. i *know* that we don't have - and can't use - 32-bit hardware for primary development purposes. i'm writing this on a 2.5 year old gaming laptop that was the fastest high-end resourced machine i could buy at the time (16GB RAM, 512mb NVMe, 3.6ghz quad-core hyperthreaded). and y'know what? given that we're *not* being paid by these users of 32-bit hardware - in fact most of us are not being paid *at all* - it's not as unreasonable as it first sounds. i am *keenly aware* that we volunteer our time, and are not paid *anything remotely* close to what we should be paid, given the responsibility and the service that we provide to others. it is a huge "pain in the ass" conundrum, that leaves each of us with a moral and ethical dilemma that we each *individually* have to face. l.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Wed, Aug 14, 2019 at 5:13 PM Aurelien Jarno wrote: > > a proper fix would also have the advantage of keeping linkers for > > *other* platforms (even 64 bit ones) out of swap-thrashing, saving > > power consumption for build hardware and costing a lot less on SSD and > > HDD regular replacements. > > That would only fix ld, which is only a small part of the issue. Do you > also have ideas about how to fix llvm, gcc or rustc which are also > affected by virtual memory exhaustion on 32-bit architectures? *deep breath* - no. or, you're not going to like it: it's not a technical solution, it's going to need a massive world-wide sustained and systematic education campaign, written in reasonable and logical language, explaining and advising GNU/Linux applications writers to take more care and to be much more responsible about how they put programs together. a first cut at such a campaign would be: * designing of core critical libraries to be used exclusively through dlopen / dlsym. this is just good library design practice in the first place: one function and one function ONLY is publicly exposed, returning a pointer to a table-of-functions (samba's VFS layer for example [1]). * compile-time options that use alternative memory-efficient algorithms instead of performance-efficient ones * compile-time options to remove non-essentlal resource-hungry features * compiling options in Makefiles that do not assume that there is vast amounts of memory available (KDE "developer" mode for example would compile c++ objects individually whereas "maintainer" mode would auto-generate a file that #included absolutely every single .cpp file into one, because it's "quicker"). * potential complete redesigns using IPC/RPC modular architectures: applying the "UNIX Philosophy" however doing so through a runtime binary self-describing "system" specifically designed for that purpose. *this is what made Microsoft [and Apple] successful*. that means a strategic focus on getting DCOM for UNIX up and running [2]. god no please not d-bus [3] [4]. also, it's going to need to be made clear to people - diplomatically but clearly - that whilst they're developing on modern hardware (because it's what *they* can afford, and what *they* can get - in the West), the rest of the world (particularly "Embedded" processors) simply does not have the money or the resources that they do. unfortunately, here, the perspective "i'm ok, i'm doing my own thing, in my own free time, i'm not being paid to support *your* hardware" is a legitimate one. now, i'm not really the right person to head such an effort. i can *identify* the problem, and get the ball rolliing on a discussion: however with many people within debian alone having the perspective that everything i do, think or say is specifically designed to "order people about" and "tell them what to do", i'm disincentivised right from the start. also, i've got a thousand systems to deliver as part of a crowd-funding campaign [and i'm currently also dealing wiith designing the Libre RISC-V CPU/GPU/VPU] as of right now those thousand systems - 450 of them are going to have to go out with Debian/Testing 8. there's no way they can go out with Debian 10. why? because this first revision hardware - designed to be eco-conscious - uses an Allwinner A20 and only has 2GB of RAM [upgrades are planned - i *need* to get this first version out, first] with Debian 10 requiring 4GB of RAM primarily because of firefox, they're effectively useless if they're ever "upgraded" that's a thousand systems that effectively go straight into landfill. l. [1] https://www.samba.org/samba/docs/old/Samba3-Developers-Guide/vfs.html#id2559133 [2] incredibly, Wine has had DCOM and OLE available and good enough to use, for about ten years now. it just needs "extracting" from the Wine codebase. DCOM stops all of the arguments over APIs (think "libboost". if puzzled, add debian/testing and debian/old-stable to /etc/apt/sources.lst, then do "apt-cache search boost | wc") due to DCOM providing "a means to publish a runtime self-describing language-independent interface", 30-year-old WIN32 OLE binaries for which the source code has been irretrievably lost will *still work* and may still be used, in modern Windows desktops today. Mozilla ripped out XPCOM because although it was "inspired" by COM, they failed, during its initial design, to understand why Co-Classes exist. as a result it caused massive ongoing problems for 3rd party java and c++ users, due to binary incompatibility caused by changes to APIs on major releases. Co-Classes were SPECIFICALLY designed to stop EXACTLY that problem... and Mozilla failed to add it to XPCOM. bottom line: the free software community has, through "hating" on microsoft, rejected the very technology that made microsoft so successful in the first place. Microsoft used DCOM (and OLE), Apple (thanks to Steve's playtime / break doing NeXT) developed Objective-C / Objective-J / Objectiv
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Aug 8, 2019 at 9:39 PM Aurelien Jarno wrote: > We are at a point were we should probably look for a real solution > instead of relying on tricks. *sigh* i _have_ been pointing out for several years now that this is a situation that is going to get increasingly worse and worse, leaving perfectly good hardware only fit for landfill. i spoke to Dr Stallman about the lack of progress here: https://sourceware.org/bugzilla/show_bug.cgi?id=22831 he expressed some puzzlement as the original binutils algorithm was perfectly well capable of handling linking with far less resident memory than was available at the time - and did *NOT*, just like gcc - assume that virtual memory was "the way to go". this because the algorithm used in ld was written at a time when virtual memory was far from adequate. then somewhere in the mid-90s, someone went "4GB is enough for anybody" and ripped the design to shreds, making the deeply flawed and short-sighted assumption that application linking would remain - forever - below 640k^H^H^H^H4GB. now we're paying the price. the binutils-gold algorithm (with options listed in the bugreport, a is *supposed* to fix this, however the ld-torture test that i created shows that the binutils-gold algorithm is *also* flawed: it probably uses mmap when it is in *no way* supposed to. binutils with the --no-keep-memory option actually does far better than binutils-gold... in most circumstances. however it also spuriously fails with inexplicable errors. basically, somebody needs to actually properly take responsibility for this and get it fixed. the pressure will then be off: linking will take longer *but at least it will complete*. i've written the ld-torture program - a random function generator - so that it can be used to easily generate large numbers of massive c source files that will hit well over the 4GB limit at link time. so it's easily reproducible. l. p.s. no, going into virtual memory is not acceptable. the cross-referencing instantly creates a swap-thrash scenario, that will put all and any builds into 10 to 100x the completion time. any link that goes into "thrash" will take 2-3 days to complete instead of an hour. "--no-keep-memory" is supposed to fix that, but it is *NOT* an option on binutils-gold, it is *ONLY* available on the *original* binutils-ld.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker wrote: > > Hi Aurelien, > > On 8/8/19 10:38 PM, Aurelien Jarno wrote: > > > 32-bit processes are able to address at maximum 4GB of memory (2^32), > > and often less (2 or 3GB) due to architectural or kernel limitations. > > [...] > > Thanks for bringing this up. > > > 1) Build a 64-bit compiler targeting the 32-bit corresponding > > architecture and install it in the 32-bit chroot with the other > > 64-bit dependencies. This is still a kind of cross-compiler, but the > > rest of the build is unchanged and the testsuite can be run. I guess > > it *might* be something acceptable. release-team, could you please > > confirm? > > As you noted, our current policy doesn't allow that. However, we could > certainly consider reevaluating this part of the policy if there is a > workable solution. it was a long time ago: people who've explained it to me sounded like they knew what they were talking about when it comes to insisting that builds be native. fixing binutils to bring back the linker algorithms that were short-sightedly destroyed "because they're so historic and laughably archaic why would we ever need them" should be the first and only absolute top priority. only if that catastrophically fails should other options be considered. with the repro ld-torture code-generator that i wrote, and the amount of expertise there is within the debian community, it would not surprise me at all if binutils-ld could be properly fixed extremely rapidly. a proper fix would also have the advantage of keeping linkers for *other* platforms (even 64 bit ones) out of swap-thrashing, saving power consumption for build hardware and costing a lot less on SSD and HDD regular replacements. l.
Re: Recreating history of a package
On Sun, 17 Feb 2019 at 12:59, Timo Weingärtner wrote: > 16.02.19 21:24 Ben Hutchings: > > On Sat, 2019-02-16 at 14:17 +0100, Guillem Jover wrote: > > > http://snapshot.debian.org/ is now offered over https too. Its front-page > > > even documents its usage as such. :) > > And it has HSTS, which is nice, but it is missing the redirection > > that's needed to make that work completely. > > I guess global HTTP redirects might break older apt setups without apt- > transport-https installed. > > For browsers it should be enough to add the redirects for the HTML pages. Feel free to redirect this to an appropriate list, but perhaps redirecting non-`apt` user agents is worthwhile? E.g. something like the solution detailed[1] for nginx. (I'm sure there's something easier for Apache). Happy to send a patch if that'd be appreciated :) [1]: https://serverfault.com/a/825725/880 -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello PGP fprint: 8C82 3DED 10AA 8041 639E 1210 5ACE 8D6E 0C14 A470
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Mon, Jan 7, 2019 at 11:30 PM Mike Hommey wrote: > > it would be extremely useful to confirm that 32-bit builds can in fact > > be completed, simply by adding "-Wl no-keep-memory" to any 32-bit > > builds that are failing at the linker phase due to lack of memory. > > Note that Firefox is built with --no-keep-memory > --reduce-memory-overheads, and that was still not enough for 32-bts > builds. GNU gold instead of BFD ld was also given a shot. That didn't > work either. Presently, to make things link at all on 32-bits platforms, > debug info is entirely disabled. I still need to figure out what minimal > debug info can be enabled without incurring too much memory usage > during linking. hi mike, hi steve, i did not receive a response on the queries about the additional recommended options [1], so rather than lose track i raised a bugreport and cross-referenced this discussion: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919882 personally, after using the ld-evil-linker.py tool i do not expect the recommended options to work on 32-bit, as i suspect that, despite the options saying that they do not use mmap, the investigation that i did provides some empirical evidence to the contrary, whereas ld-bfd does *not*. so, ironically, on ld-bfd you run into one bug, and on ld-gold you run into another :) l. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22831#c25
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 sorry using phone to type, mike, comment 25 shows some important options to ld gold would it be possible to retry with those? 32 bit. Disabling mmap looks really important as clearly a 4gb+ binary is guaranteed going to fail to fit into 32bit mmap. On Tuesday, January 8, 2019, Mike Hommey wrote: > > Note that Firefox is built with --no-keep-memory > --reduce-memory-overheads, and that was still not enough for 32-bits > builds. GNU gold instead of BFD ld was also given a shot. That didn't > work either. Presently, to make things link at all on 32-bits platforms, > debug info is entirely disabled. I still need to figure out what minimal > debug info can be enabled without incurring too much memory usage > during linking. > > Mike > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Tue, Jan 8, 2019 at 7:26 AM Luke Kenneth Casson Leighton wrote: > > On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton > wrote: > trying this: > > $ python evil_linker_torture.py 3000 400 200 50 > > running with "make -j4" is going to take a few hours. ok so that did the trick: got to 4.3gb total resident memory even with --no-keep-memory tacked on to the link. fortunately it bombed out (below) before it could get to the (assumed) point where it would double the amount of resident RAM (8.6GB) and cause my laptop to go into complete thrashing meltdown. hypothetically it should have created an 18 GB executable. 3000 times 500,000 static chars isn't the only reason this is failing, because when restricted to only 100 functions and 100 random calls per function, it worked. ok so i'm retrying without --no-keep-memory... and it's now gone beyond the 5GB mark. backgrounding it and letting it progress a few seconds at a time... that's interesting up to 8GB... 9.5GB ok that's enough: any more than that and i really will trash the laptop. ok so the above settings will definitely do the job (and seem to have thrown up a repro candidate for the issue you were experiencing with firefox builds, mike). i apologise that it takes about 3 hours to build all 3,000 6mb object files, even with a quad-core 3.6ghz i7. they're a bit monstrous. will find this post somewhere on debian-devel archives and cross-reference it here https://sourceware.org/bugzilla/show_bug.cgi?id=22831 ld: warning: cannot find entry symbol _start; defaulting to 00401000 ld: src9.o: in function `fn_9_0': /home/lkcl/src/ld_torture/src9.c:3006:(.text+0x27): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_1149_322' defined in .text section in src1149.o ld: /home/lkcl/src/ld_torture/src9.c:3008:(.text+0x41): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_1387_379' defined in .text section in src1387.o ld: /home/lkcl/src/ld_torture/src9.c:3014:(.text+0x8f): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_1821_295' defined in .text section in src1821.o ld: /home/lkcl/src/ld_torture/src9.c:3015:(.text+0x9c): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_1082_189' defined in .text section in src1082.o ld: /home/lkcl/src/ld_torture/src9.c:3016:(.text+0xa9): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_183_330' defined in .text section in src183.o ld: /home/lkcl/src/ld_torture/src9.c:3024:(.text+0x111): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_162_394' defined in .text section in src162.o ld: /home/lkcl/src/ld_torture/src9.c:3026:(.text+0x12b): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_132_235' defined in .text section in src132.o ld: /home/lkcl/src/ld_torture/src9.c:3028:(.text+0x145): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_1528_316' defined in .text section in src1528.o ld: /home/lkcl/src/ld_torture/src9.c:3029:(.text+0x152): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_1178_357' defined in .text section in src1178.o ld: /home/lkcl/src/ld_torture/src9.c:3031:(.text+0x16c): relocation truncated to fit: R_X86_64_PLT32 against symbol `fn_1180_278' defined in .text section in src1180.o ld: /home/lkcl/src/ld_torture/src9.c:3035:(.text+0x1a0): additional relocation overflows omitted from the output ^Cmake: *** Deleting file `main' make: *** [main] Interrupt
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton wrote: > i'm going to see if i can get above the 4GB mark by modifying the > Makefile to do 3,000 shared libraries instead of 3,000 static object > files. fail. shared libraries link extremely quickly. reverted to static, trying this: $ python evil_linker_torture.py 3000 400 200 50 so that's 4x the number of functions per file, and 2x the number of calls *in* each function. just the compile phase requires 1GB per object file (gcc 7.3.0-29), which, on "make -j8" ratched up the loadavg to the point where... well.. *when* it recovered it reported a loadavg of over 35, with 95% usage of the 16GB swap space... running with "make -j4" is going to take a few hours. l.
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
$ python evil_linker_torture.py 3000 100 100 50 ok so that managed to get up to 1.8GB resident memory, paused for a bit, then doubled it to 3.6GB, and a few seconds later successfully outputted a binary. i'm going to see if i can get above the 4GB mark by modifying the Makefile to do 3,000 shared libraries instead of 3,000 static object files. l.
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Tue, Jan 8, 2019 at 6:27 AM Luke Kenneth Casson Leighton wrote: > i'm just running the above, will hit "send" now in case i can't hit > ctrl-c in time on the linker phase... goodbye world... :) $ python evil_linker_torture.py 2000 50 100 200 $ make -j8 oh, err... whoopsie... is this normal? :) it was only showing around 600mb during the linker phase anyway. will keep hunting. where is this best discussed (i.e. not such a massive cc list)? /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o: in function `deregister_tm_clones': crtstuff.c:(.text+0x3): relocation truncated to fit: R_X86_64_PC32 against `.tm_clone_table' /usr/bin/ld: crtstuff.c:(.text+0xb): relocation truncated to fit: R_X86_64_PC32 against symbol `__TMC_END__' defined in .data section in main /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o: in function `register_tm_clones': crtstuff.c:(.text+0x43): relocation truncated to fit: R_X86_64_PC32 against `.tm_clone_table' /usr/bin/ld: crtstuff.c:(.text+0x4a): relocation truncated to fit: R_X86_64_PC32 against symbol `__TMC_END__' defined in .data section in main /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o: in function `__do_global_dtors_aux': crtstuff.c:(.text+0x92): relocation truncated to fit: R_X86_64_PC32 against `.bss' /usr/bin/ld: crtstuff.c:(.text+0xba): relocation truncated to fit: R_X86_64_PC32 against `.bss' collect2: error: ld returned 1 exit status make: *** [main] Error 1
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
$ python evil_linker_torture.py 2000 50 100 200
ok so it's pretty basic, and arguments of "2000 50 10 100"
resulted in around a 10-15 second linker phase, which top showed to be
getting up to around the 2-3GB resident memory range. "2000 50 100
200" should start to make even a system with 64GB RAM start to
feel the pain.
evil_linker_torture.py N M O P generates N files with M functions
calling O randomly-selected functions where each file contains a
static char of size P that is *deliberately* put into the code segment
by being initialised with a non-zero value, exactly and precisely as
you should never do because... surpriiise! it adversely impacts the
binary size.
i'm just running the above, will hit "send" now in case i can't hit
ctrl-c in time on the linker phase... goodbye world... :)
l.
#!/usr/bin/env python
import sys
import random
maketemplate = """\
CC := gcc
CFILES:=$(shell ls | grep "\.c")
OBJS:=$(CFILES:%.c=%.o)
DEPS := $(CFILES:%.c=%.d)
CFLAGS := -g -g -g
LDFLAGS := -g -g -g
%.d: %.c
$(CC) $(CFLAGS) -MM -o $@ $<
%.o: %.c
$(CC) $(CFLAGS) -o $@ -c $<
# $(CC) $(CFLAGS) -include $(DEPS) -o $@ $<
main: $(OBJS)
$(CC) $(OBJS) $(LDFLAGS) -o main
"""
def gen_makefile():
with open("Makefile", "w") as f:
f.write(maketemplate)
def gen_headers(num_files, num_fns):
for fnum in range(num_files):
with open("hdr{}.h".format(fnum), "w") as f:
for fn_num in range(num_fns):
f.write("extern int fn_{}_{}(int arg1);\n".format(fnum, fn_num))
def gen_c_code(num_files, num_fns, num_calls, static_sz):
for fnum in range(num_files):
with open("src{}.c".format(fnum), "w") as f:
for hfnum in range(num_files):
f.write('#include "hdr{}.h"\n'.format(hfnum))
f.write('static char data[%d] = {1};\n' % static_sz)
for fn_num in range(num_fns):
f.write("int fn_%d_%d(int arg1)\n{\n" % (fnum, fn_num))
f.write("\tint arg = arg1 + 1;\n")
for nc in range(num_calls):
cnum = random.randint(0, num_fns-1)
cfile = random.randint(0, num_files-1)
f.write("\targ += fn_{}_{}(arg);\n".format(cfile, cnum))
f.write("\treturn arg;\n")
f.write("}\n")
if fnum != 0:
continue
f.write("int main(int argc, char *argv[])\n{\n")
f.write("\tint arg = 0;\n")
for nc in range(num_calls):
cnum = random.randint(0, num_fns-1)
cfile = random.randint(0, num_files-1)
f.write("\targ += fn_{}_{}(arg);\n".format(cfile, cnum))
f.write("\treturn 0;\n")
f.write("}\n")
if __name__ == '__main__':
num_files = int(sys.argv[1])
num_fns = int(sys.argv[2])
num_calls = int(sys.argv[3])
static_sz = int(sys.argv[4])
gen_makefile()
gen_headers(num_files, num_fns)
gen_c_code(num_files, num_fns, num_calls, static_sz)
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Tuesday, January 8, 2019, Mike Hommey wrote: > On Mon, Jan 07, 2019 at 11:46:41PM +0000, Luke Kenneth Casson Leighton > wrote: > > > At some point apps are going to become so insanely large that not even > > disabling debug info will help. > > That's less likely, I'd say. Debug info *is* getting incredibly more and > more complex for the same amount of executable weight, and linking that > is making things worse and worse. But having enough code to actually be > a problem without debug info is probably not so close. > > It's a slow boil problem, taken 10 years to get bad, another 10 years to get really bad. Needs strategic planning. Right now things are not exactly being tackled except in a reactive way, which unfortunately takes time as everyone is volunteers. Exacerbates the problem and leaves drastic "solutions" such as "drop all 32 bit support". > There are solutions to still keep full debug info, but the Debian > packaging side doesn't support that presently: using split-dwarf. It > would probably be worth investing in supporting that. > > Sounds very reasonable, always wondered why debug syms are not separated at build/link, would buy maybe another decade? -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Tuesday, January 8, 2019, Mike Hommey wrote: > . > > Note that Firefox is built with --no-keep-memory > --reduce-memory-overheads, and that was still not enough for 32-bts > builds. GNU gold instead of BFD ld was also given a shot. That didn't > work either. Presently, to make things link at all on 32-bits platforms, > debug info is entirely disabled. I still need to figure out what minimal > debug info can be enabled without incurring too much memory usage > during linking. Dang. Yes, removing debug symbols was the only way I could get webkit to link without thrashing, it's a temporary fix though. So the removal of the algorithm in ld Dr Stallman wrote, dating back to the 1990s, has already resulted in a situation that's worse than I feared. At some point apps are going to become so insanely large that not even disabling debug info will help. At which point perhaps it is worth questioning the approach of having an app be a single executable in the first place. Even on a 64 bit system if an app doesn't fit into 4gb RAM there's something drastically going awry. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
(hi edmund, i'm reinstating debian-devel on the cc list as this is not
a debian-arm problem, it's *everyone's* problem)
On Mon, Jan 7, 2019 at 12:40 PM Edmund Grimley Evans
wrote:
> > i spoke with dr stallman a couple of weeks ago and confirmed that in
> > the original version of ld that he wrote, he very very specifically
> > made sure that it ONLY allocated memory up to the maximum *physical*
> > resident available amount (i.e. only went into swap as an absolute
> > last resort), and secondly that the number of object files loaded into
> > memory was kept, again, to the minimum that the amount of spare
> > resident RAM could handle.
>
> How did ld back then determine how much physical memory was available,
> and how might a modern reimplemention do it?
i don't know: i haven't investigated the code. one clue: gcc does
exactly the same thing (or, used to: i believe that someone *may* have
tried removing the feature from recent versions of gcc).
... you know how gcc stays below the radar of available memory, never
going into swap-space except as a last resort?
> Perhaps you use sysconf(_SC_PHYS_PAGES) or sysconf(_SC_AVPHYS_PAGES).
> But which? I have often been annoyed by how "make -j" may attempt
> several huge linking phases in parallel.
on my current laptop, which was one of the very early quad core i7
skylakes with 2400mhz DDR4 RAM, the PCIe bus actually shuts down if
too much data goes over it (too high a power draw occurs).
consequently, if swap-thrashing occurs, it's extremely risky, as it
causes the NVMe SSD to go *offline*, re-initialise, and come back on
again after some delay.
that means that i absolutely CANNOT allow the linker phase to go into
swap-thrashing, as it will result in the loadavg shooting up to over
120 within just a few seconds.
> Would it be possible to put together a small script that demonstrates
> ld's inefficient use of memory? It is easy enough to generate a big
> object file from a tiny source file, and there are no doubt easy ways
> of measuring how much memory a process used, so it may be possible to
> provide a more convenient test case than "please try building Firefox
> and watch/listen as your SSD/HDD gets t(h)rashed".
>
> extern void *a[], *b[];
> void *c[1000] = { &a };
> void *d[1000] = { &b };
>
> If we had an easy test case we could compare GNU ld, GNU gold, and LLD.
a simple script that auto-generated tens of thousands of functions in
a couple of hundred c files, with each function making tens to
hundreds of random cross-references (calls) to other functions across
the entire range of auto-generated c files should be more than
adequate to make the linker phase go into near-total meltdown.
the evil kid in me really *really* wants to give that a shot...
except it would be extremely risky to run on my laptop.
i'll write something up. mwahahah :)
l.
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Sun, Jan 6, 2019 at 11:46 PM Steve McIntyre wrote: > > [ Please note the cross-post and respect the Reply-To... ] > > Hi folks, > > This has taken a while in coming, for which I apologise. There's a lot > of work involved in rebuilding the whole Debian archive, and many many > hours spent analysing the results. You learn quite a lot, too! :-) > > I promised way back before DC18 that I'd publish the results of the > rebuilds that I'd just started. Here they are, after a few false > starts. I've been rebuilding the archive *specifically* to check if we > would have any problems building our 32-bit Arm ports (armel and > armhf) using 64-bit arm64 hardware. I might have found other issues > too, but that was my goal. very cool. steve, this is probably as good a time as any to mention a very specific issue with binutils (ld) that has been slowly and inexorably creeping up on *all* distros - both 64 and 32 bit - where the 32-bit arches are beginning to hit the issue first. it's a 4GB variant of the "640k should be enough for anyone" problem, as applied to linking. i spoke with dr stallman a couple of weeks ago and confirmed that in the original version of ld that he wrote, he very very specifically made sure that it ONLY allocated memory up to the maximum *physical* resident available amount (i.e. only went into swap as an absolute last resort), and secondly that the number of object files loaded into memory was kept, again, to the minimum that the amount of spare resident RAM could handle. some... less-experienced people, somewhere in the late 1990s, ripped all of that code out [what's all this crap, why are we not just relying on swap, 4GB swap will surely be enough for anybody"] by 2008 i experienced a complete melt-down on a 2GB system when compiling webkit. i tracked it down to having accidentally enabled "-g -g -g" in the Makefile, which i had done specifically for one file, forgot about it, and accidentally recompiled everything. that resulted in an absolute thrashing meltdown that nearly took out the entire laptop. the problem is that the linker phase in any application is so heavy on cross-references that the moment the memory allocated by the linker goes outside of the boundary of the available resident RAM it is ABSOLUTELY GUARANTEED to go into permanent sustained thrashing. i cannot emphasise enough how absolutely critical that this is to EVERY distribution to get this fixed. resources world-wide are being completely wasted (power, time, and the destruction of HDDs and SSDs) because systems which should only really take an hour to do a link are instead often taking FIFTY times longer due to swap thrashing. not only that, but the poor design of ld is beginning to stop certain packages from even *linking* on 32-bit systems! firefox i heard now requires SEVEN GIGABYTES during the linker phase! and it's down to this very short-sighted decision to remove code written by dr stallman, back in the late 1990s. it would be extremely useful to confirm that 32-bit builds can in fact be completed, simply by adding "-Wl no-keep-memory" to any 32-bit builds that are failing at the linker phase due to lack of memory. however *please do not make the mistake of thinking that this is specifically a 32-bit problem*. resources are being wasted on 64-bit systems by them going into massive thrashing, just as much as they are on 32-bit ones: it's just that if it happens on a 32-bit system a hard error occurs. somebody needs to take responsibility for fixing binutils: the maintainer of binutils needs help as he does not understand the problem. https://sourceware.org/bugzilla/show_bug.cgi?id=22831 l.
Re: Nix and non-standard-toplevel-dir
On Wed, 2 Jan 2019 at 20:28, Russ Allbery wrote: > If anything, they probably already know > how Nix works and are expecting it to use those paths. There doesn't seem > to be much drawback in this carefully-chosen lack of compliance with the > FHS. > > I don't think it's worth writing an explicit Policy exception for this, > since it's a single edge case. Instead, I think it's a good use of a > Lintian override documenting what's going on. Obviously, if Nix becomes > really popular in the long run, we can then go back and write this into > Policy. This also is the case with snapd, which uses `/snap` in all other distributions. We currently override it, but the issue was brought up in a bug report.[1] I think the same arguments apply to both Nix and snapd; but perhaps two is not yet numerous enough to warrant documenting in policy. [1]: http://bugs.debian.org/852199 Cheers, Luke Faraone
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer wrote: > So: what's the best outcome for our *current* users? Again, pick only one. here's a perspective that may not have been considered: how much influence and effect on purchasing decisions would the choice made have? we know that proprietary embedded GPUs and associated proprietary software are not just unethical, and cause huge problems, they also hurt company profits and cause increases in support costs. by complete contrast, when all the source code is libre-licensed, this is what happens: http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develop-open-source-graphics-drivers-1649632.html basically what i am inviting you to consider is that in making this decision, the one that supports, encourages and indirectly endorses the continued propagation of proprietary 3D libraries is one that is going to have a massive world-wide adverse financial impact over time. i would therefore strongly recommend prioritising decisions that support libre-licensed GPU firmware and PCIe GPU cards that have libre-licensed source code. if systems with etnaviv are "punished" for example by this decision, that would not go down too well. if people running older Radeon GPU Cards (on the RockPro64 which has a 4x PCIe Card that easily runs at 2500 MBytes/sec) find that their cards perform badly, that is also not going to go down well. bottom line: your decisions here have far more impact than you may realise. l.
Re: libsrt - srt - Secure Reliable Transport add Debian Package
Hello, On 29/08/2018 15:18, Tudor Suciu wrote: > libsrt is a useful library for live video broadcasts. It is already > integrated in ffmpeg, gstreamer and vlc. > I propose this debian package for inclusion: > https://bitbucket.org/tudorsuciu/srt > Please tell me if you have issues generating a deb package/integrating with > ffmpeg/gstreamer/vlc. If you're intending to maintain this package in Debian, you should file an "Intent to Package" bug[1]. After that, you can follow the processes on mentors.debian.net[2][3] to request sponsorship of your package. For this library specifically, I suspect you might have luck engaging with the Debian Multimedia Team — they address your type of request in their team-specific FAQ[4]. Thank you for your contribution to Debian! Cheers, Luke Faraone [1]: https://www.debian.org/devel/wnpp/ [2]: https://mentors.debian.net/intro-maintainers [3]: https://mentors.debian.net/sponsors [4]: https://wiki.debian.org/DebianMultimedia/FAQ#I_have_packaged_new_software._Can_you_upload_it_for_me.3F signature.asc Description: OpenPGP digital signature
Re-evaluating architecture inclusion in unstable/experimental
(resending with corrected address for debian-bsd) Dear ports maintainer, The ftpmaster team would like to clarify which Debian ports should and/or would like to continue to be part of Debian unstable and experimental. As outlined on the Debian Archive Criteria page[0], the key points to consider are whether the architecture has been part of a stable release, whether it is *likely* to be part of a stable release, as well as whether it currently has a sensible number of active maintainers. Whilst you may be happy to continue the work of maintaining the port regardless, don't forget that excess or otherwise unnecessary architectures involve a shared maintenance burden as well as incurring non-trivial requirements on mirror/Debian resources. The statistics and graphs available on the debian-ports page[1] may provide some objective statistics or reflection on the actual suitability of your architecture's continued inclusion. So, in the first instance, would you like to continue being part of unstable/experimental? [0]: https://ftp-master.debian.org/archive-criteria.html [1]: https://buildd.debian.org/stats/ Cheers, Luke Faraone signature.asc Description: OpenPGP digital signature
Re-evaluating architecture inclusion in unstable/experimental
Dear ports maintainer, The ftpmaster team would like to clarify which Debian ports should and/or would like to continue to be part of Debian unstable and experimental. As outlined on the Debian Archive Criteria page[0], the key points to consider are whether the architecture has been part of a stable release, whether it is *likely* to be part of a stable release, as well as whether it currently has a sensible number of active maintainers. Whilst you may be happy to continue the work of maintaining the port regardless, don't forget that excess or otherwise unnecessary architectures involve a shared maintenance burden as well as incurring non-trivial requirements on mirror/Debian resources. The statistics and graphs available on the debian-ports page[1] may provide some objective statistics or reflection on the actual suitability of your architecture's continued inclusion. So, in the first instance, would you like to continue being part of unstable/experimental? [0]: https://ftp-master.debian.org/archive-criteria.html [1]: https://buildd.debian.org/stats/ Cheers, Luke Faraone signature.asc Description: OpenPGP digital signature
Re: why hasn't the debian transition freeze been announced or shared in debin testing info. or bits.debian.org ?
On 26 April 2018 at 00:16, shirish शिरीष wrote: > I had read > https://lists.debian.org/debian-devel-announce/2018/04/msg6.html > so knew when the transition freeze is going to happen. For a blog > post/technical article I wanted to share about the transition freeze > and went to https://www.debian.org/releases/testing/ as well as > https://bits.debian.org/ but neither seems to have that info. > > Shouldn't be the milestone including perhaps info. on tentative alpha > releases be put somewhere or are the dates subject to change ? > > If the dates are locked down, it would be nicer to be able to > share/link to an official page on debian website rather than just an > e-mail. Messages to debian-devel-announce@ by DPL delegates within the scope of their responsibilities are official. This is explicitly called out in /releases/testing: |> In addition, general status reports are posted by the release manager to the debian-devel-announce mailing list. Cheers, Luke W Faraone
Re: Please do not drop Python 2 modules
Hi Holger, On 23/04/18 03:11, Holger Levsen wrote: > On Mon, Apr 23, 2018 at 01:52:19AM +, Scott Kitterman wrote: >> Fundamentally not a lintian warnings are created equal. Some have solid >> foundation in Debian project consensus and policy. Others are nothing >> more than the opinions of the lintian maintainers. This is one of the >> latter. > > you make it sound like the lintian maintainers are a bunch of lunatics, > but according to src:piuparts/debian/copyright, that's us, the piuparts > maintainers. the lintian maintainers (and uploaders) are a bunch of > (ex- and current) people from the release team, ftp team, policy editors > and others. I can understand that the above is one reading of Scott's mail, but I personally didn't take anything super negatively w.r.t. "nothing more than the opinions of the lintian maintainers". But again, in the context of my mail, I was (quite verbosely) outlining that Lintian's findings may sometimes be, on their own, sufficient justifications for a REJECT, and sometimes not. Even a Lintian warning may still result in a REJECT if it was clear it was 100% apt, and represents something we don't want in the archive. > and, afaik, they react to bug reports. maybe for now this python2 warning > should be downgraded to 'info'? what would be the best way to tell them I agree, people who feel strongly this issue is misclassified could best instigate action by taking this discussion to a bug (perhaps spilling over to debian-devel if it is in fact of interest to the wider project for discussion). Cheers, Luke W Faraone signature.asc Description: OpenPGP digital signature
Re: Please do not drop Python 2 modules
On 22/04/18 23:52, Julien Muchembled wrote: > A lintian warning is even a reason for REJECT. Technically yes, Lintian warnings and errors are a thing that ftpteam looks at when processing new packages. But if all Lintian warnings without an override were cause for reject, we'd just configure dak to do that work for us, no need to spend time reading the package. In fact we do this for a set of Lintian warnings/errors with minimal false-positives[1]. We're human, we're going to think about whether it makes sense, whether it's a particularly egregious screwup that will make the archive worse, whether it's a false-positive or otherwise ignorable, etc. > "I" (my mentor) uploaded a new source package "zodbpickle" 5 weeks ago and I > wonder if it's stuck because of this. If that were the case, you should have gotten mail about it. (either a prod for more information, or a REJECT) Looking at the current state of the queue[1], there are a number of (non-node) packages ahead of your package. As far as I can tell, it just hasn't been reviewed yet. > The ITP contains a link to an email where I explain why it is needed: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842870 > (to sum up: required dependency in order to package a new version of ZODB > with support for Python 3) > > But I don't want to drop the Python 2 module of ZODB. That's what I only use > for the moment. Great! Then don't! From the Lintian warning text: Python 2.x modules should not be packaged unless strictly necessary (such as being explicitly requested by an end-user or required as part of a dependency chain) as the 2.x series of Python is due for deprecation and will not be maintained past 2020. > I found strange to put an override for this so I didn't. While not required, including an override is a sign to other Debian developers that "yes, I thought about this and it is not applicable for this reason". So I think it would have been good to include one, but not absolutely required. Cheers, Luke W Faraone signature.asc Description: OpenPGP digital signature
Re: Please do not drop Python 2 modules
On Sat, Apr 21, 2018 at 9:19 PM, Scott Kitterman wrote: > On April 21, 2018 9:05:27 PM UTC, Jeremy Bicha wrote: >>You and I seem to be clashing a bit often on the issue of when it is >>appropriate to remove obsolete packages from Debian. It seems like >>some of your resistance is a bit theoretical. It sounds to me like >>you're saying don't remove any Python2 libraries because somebody >>somewhere might find it inconvenient to need to port some third-party >>app to Python3 before 2022. But I think if we had that philosophy, we >>wouldn't ever remove anything until identified security concerns force >>it out. > > Since we are supporting Python2 in the next release, there is no value in > dumping python-* packages now. Unlike many areas of the archive, Python > packages are actively used by third-party code that isn't and won't be in > Debian. > > I've personally invested time and political capital in external projects I've > worked on to get people to use Debian packages as a stable base and not just > download semi-random code from wherever. Please don't make this harder. +100 to this. Even at a previous life in a fast-moving startup, I convinced the rest of engineering that "if you want to use it, and it isn't in Debian, you get to package it first". (aside, also had the advantage of convincing people to use more commonly-used packages, rather than some random fork of a fork they found one day…) Cheers, Luke Faraone
Re: Urging for solution to the slow NEW queue process
On 11/04/18 16:12, Jonathan Carter (highvoltage) wrote:>> On Wed, Apr 11, 2018 at 07:08:21AM +, Lumin wrote: >>> I'm only a DM and I tried to apply for FTP assistant […] The 2010[1] and 2017[2] call for help both said that one needs to be a DD, unless one is solely helping with dak (which is not ftpassistant). It is hard to justify granting NEW reviewer bits if one does not already have unrestricted upload to the archive. [1]: https://lists.debian.org/debian-devel-announce/2010/03/msg3.html [2]: https://lists.debian.org/debian-devel/2017/08/msg00408.html > I had a similar experience. It didn't help that the one ftp-master > member made a comment about laughing off requests to join the ftp team. > If they didn't want my help I'd rather get a "sorry, we don't think > you're experienced enough yet" rather than just nothing. I reviewed the relevant conversation in #debian-ftp. I think if you re-read it, the context makes it pretty clear that it was certainly not "laughing off the request" — you said something along the lines of "my destiny is sealed" and the response was, jokingly, you could be freed from that destiny by a rejection. [Then again, the conversation was in a language I do not speak, so maybe there's nuance that did not translate.] I can assure you that your request to join was not silently declined, and has yet to be processed due to lack of time. We have onboarded several FTP trainees since the August 2017 call, but they are generally done in batches. Cheers, Luke signature.asc Description: OpenPGP digital signature
Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
Package: wnpp Severity: wishlist Owner: Luke W Faraone * Package name: powershell Version : 6.0.0~alpha9 Upstream Author : Microsoft * URL : https://github.com/PowerShell/PowerShell * License : Expat Programming Lang: C# Description : scripting language interpreter built on .NET Microsoft recently released PowerShell as free software, and this month announced support for Linux platforms. >From a parausal of the source code, it appears to be suitable for inclusion in Debian.
EOMA68-A20 Crowd-funded Laptop and Micro-Desktop
https://www.crowdsupply.com/eoma68/micro-desktop
i've been working on a strategy to make it possible for people to have
more control over the hardware that they own, and for it to cost less
money for them to do so, long-term. i've had to become an open
hardware developer in order to do that.
i believed for a long long time that leaving hardware design to the
mass-volume manufacturers would result in us having affordable
hardware that we could own. they would make stuff; we could port
OSes to it, everybody wins. starting in 2003 and working for almost
2 years continuously on reverse-engineering i got a bit of a rude but
early wake-up call where i learned just how naive that expectation
really is [1]. example: it took over THREE YEARS for cr2 to
reverse-engineer the drivers for the HTC Universal clamshell 3G
micro-laptop.
for everyone else, that message came through loud and clear with
mjg59's android tablet GPL violations list - which he stopped maintaining
because it was pointless to continue [2][3]. it was a bit of a slap in
the face - a wake-up call which not only debian but every other ARM
free software distribution is painfully reminded of on a regular basis
when someone new contacts them and asks:
"I have hardware {X} bought off of Amazon / Aliexpress, can i run
Linux on it"
and pretty much every time someone has to spend their time patiently
explaining that no, it's not possible, due to the extraordinary
amount of reverse-engineering that's required due to rampant and:
endemic GPL violations, and even if they could, it's *already too late*
due to "Single-Board Computer Supernova Lifecycle" syndrome.
shockingly even intel do not really "Get It". not only do they have
the arbitrary remote code execution backdoor co-processor [4]
in every x86_64 processor since 2009, but in speaking to a member
of the intel open source education team at fosdem2016 i learned that
intel considers something as trivial as DDR3 RAM initialisation
sequences to be "commercial advantage" and this they use as
justification for not releasing the 200 lines of code needed... not
that it would help very much because of the RSA secret key needed
to sign early boot code.
we also have the issue of proliferation of linux kernel device drivers:
put simply if there are M processors and N "types of products",
we can reasonably and rationally expect the number of submissions
of device drivers and device tree files for upstream inclusion to be of the
order of "M *TIMES* N". with "M" just in the ARM world alone being
enormous (over 650 licensees as of 10 years ago) and "N" likewise
being huge, this places a huge burden on the linux kernel developers,
and an additional burden downstream on you, the OS maintainers, as
well.
... would it not be better to have hardware that was designed around
"M plus N"? this would stop the endemic proliferation of device drivers,
would it not?
so this is the primary driving factor behind EOMA68 - to reduce the
burden of work required to be carried out by software libre developers,
as well as reduce the long-term cost of ownership of hardware for
everyone.
so after five years i can finally say that the EOMA68 standard is
ready, and with the last (and final) revision adding in USB 3.1 it
can be declared to have at least a decade of useful life ahead of
it. there are NO "options". there will be NO further changes made
(which would result in chaos). a modern Computer Card bought
10 years from now will still work with a Housing that's bought today,
and vice-versa.
if this approach is something that you feel is worthwhile supporting,
the crowd funding campaign runs for another 40 days. crowd funding
campaigns are about supporting "ideas" and being rewarded with
a gift for doing so. they're not about "buying a boxed product under
contract of sale".
with your support it will be possible to bring other designs and other
processors to you later. picking a processor has its own interesting
challenges [5] if you have ethical business considerations to take
into account, such as "don't use anything that's GPL violating or
otherwise illegal". [why *is* it that people think it's okay to sell GPL
violating products, even amongst the open hardware community?
ethical ends can never be justified by unethical means].
lastly, i'm... reluctant to bring this up, but i have to. *deep breath*.
i'm aware that a lot of people in the debian world don't like me. many
of you *genuinely* believe that i am out to control you, to tell you
what to do, to "order you about". which is nonsense, but, more
importantly, rationally-speaking, completely impossible given the
nature of free software. we can therefore conclude, rationally, that
the conclusion reached by many of you [that i am "ordering you
about"] simply cannot be true.
after thinking about this for a long, long time, my feeling is that this
startlingly and completely overwhelmingly WRONG impression
stems from my reverse-engineering background, which, wh
Bug 773245 - git-p4 package - lost in space?
Hi! I submitted a patch to the git package back in December 2014 to add the git-p4 sub-package into contrib. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773245 It seems to be lost in space somewhere, drifting alone in the cold airless vacuum between the stars, tumbling forever towards oblivion. Is there any way that we could perhaps launch a rescue mission for it, perhaps sending someone out with a jet pack and a long rope? Could we ask Nasa to divert their next mission to Mars? It's dangerous and hazardous, and after a year in space it may already be dead, but what do we think? Is there any hope for it? Thanks! Luke
Bug#803727: ITP: node-handlebars -- semantic templatating engine
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: node-handlebars Version : 4.0.4 Upstream Author : Yehuda Katz * URL : http://www.handlebarsjs.com/ * License : Expat Programming Lang: JavaScript Description : semantic templating engine Handlebars templates look like regular HTML, with embedded handlebars expressions. It has a syntax similar to the Mustache templating language. . This package contains the runtime for NodeJS. I realise there are existing ``libjs-handlebars`` and ``libjs-handlebars.runtime`` packages in the archive. They come from ``ruby-handlebars-assets``, which I assume embeds its own copy. This will not conflict with that package, but to reduce archive duplication I'll coordinate with the Ruby team and that package's maintainer.
Bug#800897: ITP: zxcvbn.js -- JavaScript password strength estimator
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: zxcvbn.js Version : 3.5.0 Upstream Author : Dan Wheeler * URL : https://github.com/dropbox/zxcvbn * License : Expat Programming Lang: JavaScript Description : JavaScript password strength estimator zxcvbn is a password strength estimator inspired by password crackers. Through pattern matching and conservative entropy calculations, it recognizes and weighs 10k common passwords, common names and surnames according to US census data, popular English words, and other common patterns like dates, repeats (aaa), sequences (abcd), keyboard patterns (qwertyuiop), and l33t speak. Motiviation for the design can be found detailed at: <http://tech.dropbox.com/?p=165> zxcvbn detects and supports CommonJS (node, browserify) and AMD (RequireJS). In the absence of those, it adds a single function zxcvbn() to the global namespace. NB: This is my first time packaging a JavaScript/AMD/Node package, so I will probably be reaching out to the Debian JS maintainers for help :)
Bug#800052: ITP: zulip-server -- group chat for teams
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: zulip-server Version : 1.3.0 Upstream Author : Dropbox * URL : https://www.zulip.org/ * License : Apache 2.0 Programming Lang: Python, JavaScript Description : group chat for teams Zulip is a group chat application optimized for software development teams. This is the server-side web application that can either be used in a web browser or via various other clients.
libre version of iceweasel
http://news.slashdot.org/story/15/06/09/1722236/mozilla-responds-to-firefox-user-backlash-over-pocket-integration after seeing this, i'm becoming increasingly alarmed at where firefox is going [the first signs were the way in which the announcement was made to focus on "speed improvements" when chrome and webkit first became popular] open question: is there a perceived need to dig into the source code of firefox and, just as was done with google-chrome to create chromium-browser, permanently patch out certain "features"? l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPweEDwH=pvRP=rwni6mgbhvp1a0jw0wqk4vgdcsznqhap_...@mail.gmail.com
Bug#782413: ITP: mahimahi -- tools for network emulation and analysis
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: mahimahi Version : 0.90 Upstream Author : Keith Winstein * URL : https://github.com/keithw/mahimahi * License : GPL-3+ Programming Lang: C++ Description : tools for network emulation and analysis Mahimahi is a suite of user-space tools for network emulation and analysis. Each mahimahi tool spawns a lightweight container, generally connected to the outside via a synthetic network device that observes packets in transit or emulates a desired behavior. The tools are composable so that a series of emulated network effects can be chained together, with mahimahi containers nested inside each other. Each tool takes an optional command to execute, so it is possible to create a series of nested containers with one command line -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150411185609.25452.98615.report...@luke-microkernel.zulip.net
Re: how to remove libsystemd0 from a live-running debian desktop system
On Wed, Feb 18, 2015 at 12:16 AM, Axel Wagner wrote:
> Luke Kenneth Casson Leighton writes:
>> what *does* concern me is that it takes such incredible (and amazing)
>> efforts by people like adam for the average end-user or sysadmin to
>> contemplate replacing {insert nameless package}.
>
> insert libc6.
libc6 has alternatives, and, itself is maintained by a diverse group
(the FSF) with a reputation for respecting software freedom and
sufficient experience to know the ropes surrounding UNIX/POSIX. even
google when developing android decided that the GPL was a horrible
virus, they didn't like libc6 and very kindly funded the creation of
an alternative. also as a well-defined standard it would be
unbelievably stupid to attempt to deviate from it ("get creative").
conclusion: we can trust the libc6 maintainers.
> Or insert perl.
perl is maintained by an extremely experienced and diverse group of
developers. they understand the responsibilities behind maintaining
and developing such a critical programming language.
conclusion: we can trust the perl developers.
> Or insert linux-image.
linux is developed by a hodge-podge bag of cat-like developers who
all, amazingly, pull together and get the job done. they're also
headed by a team of incredibly responsible people who have had decades
of experience.
conclusion: we can trust the linux kernel developers.
a previous example given was SE/Linux. i outlined a case where,
paradoxically, it can be demonstrated that we can trust the developers
behind SE/Linux.
another example i was gives was grub. grub has alternatives (lilo
and others): by inference this keeps them honest by way of
competition. conclusion: we can trust the grub developers.
> And suddenly no on cares (not even you).
the cases you give are ones where a rational analysis shows that the
people behind them can be trusted. we can go at this for as long as
you feel it useful for you to do so, but i think you will find that,
in every case, the team behind the package engender our trust (trust
is *not* earned, btw: respect is earned. trust is given. always.
past performance != guarantee of future behaviour)
but systemd is very, very different. far from being able to find
reasons why the systemd team may be trusted, analysis by several
people shows that, sadly, the complete opposite is the case.
unfortunately, the team behind the systemd project have demonstrated
time and time again that their focus is extremely narrow: Redhat
Desktop.
one example (and there are many, many more):
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
just one good analysis of which is here:
http://lists.busybox.net/pipermail/busybox/2011-September/076713.html
> You have to do better than this, sorry. Just that
> a package has reverse dependencies and that you have to recompile a big
> part of the debian archive to install a debian without them does *not*
> mean, that this package is in any way problematic
> [continued below]
you are correct about that [i.e. you are correct in the assertion
that the recompilation for removal has nothing to do with removal].
i am still trying to track down concrete reasons why i feel so
alarmed. i believe it's because everything i've seen that team do -
all their "blogs" and reports has been... it feels so "rational", and
so "logical", yet nowhere do i see any kind of debate, inclusion of
other people, other teams. do these people join mailing lists other
than those directly related to fedora desktop?
the whole situation feels desperately, desperately wrong, and i
cannot unfortunately give you a single concrete specific example or
reason why, and that is part of the problem: nobody else really can,
either.
and i think that's really why everyone has been getting so fed up,
getting into such severe arguments that they end up leaving projects
that they've worked well for decades with everyone for such a long
time.
that *in and of itself* should tell you that there's something
seriously wrong, here. how many prominent, committed, dedicated and
experienced people have resigned from roles in debian so far - people
without whom debian is clearly worse off.
> [continued here]
> or takes away choice.
on this you are wrong: by definition and by the immediate evidence
shown, it does exactly and precisely that. [more specifically, the
choices that people are forced into making are so extreme that many
cannot even make them, they are so disruptive, or require such extreme
knowledge, or require extreme risks, or require violations of company
policy - use of unofficial archives which would violate support
contracts - and so on].
l.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAPweEDzfzUx=+hzezcgpomp7ufrogfbv4k9aa-oqao+ev1g...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
On Wed, Feb 18, 2015 at 12:27 AM, Steve Langasek wrote: > On Tue, Feb 17, 2015 at 11:52:21PM +0000, Luke Kenneth Casson Leighton wrote: >> On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett >> wrote: > >> > So, please go educate yourself on what libsystemd0 actually does, > >> i know what it does, and what it does - technically - is *not* the >> issue that i am concerned about. > > And that is why you'll find little interest here in entertaining your > argument. You have *not* presented any evidence that Debian is technically > worse off as a result of packages depending on libsystemd0. that's right - i haven't. because (a) i have complete confidence in your technical abilities, as a group. i wouldn't use debian otherwise! :) and (b) this isn't a technical issue, it's a strategic one. so, the gist is: debian developers make decisions primarily based on technical merit (almost exclusively), disregarding strategic issues (almost exclusively). would that be a fairly broad but accurate assessment? (thank you to everyone else who has chipped in, i read a couple of other messages from people which point in a similar direction) a couple of things occur to me. firstly, when i was last in holland i was working for NC3A, some kind person referred me to an obscure book called "The Strategy-focussed Organisation". very intelligent guy, who had actually read it... i don't recommend reading all of it cover-to-cover, and neither did he :) he pointed out to me the one key question is that when it comes to the strategy (direction, focus) of any organisation, the question "why should we care what anyone else is doing?" is *the* most important one you can possibly ask. why - when you, the debian developers, are doing such a fantastic job (really and sincerely) - should you care when someone from *outside* of your group jumps up and down and says "uhh... guuuys?" i invite you to think seriously about that, ok? (because i don't have an answer!!) the second thing - and i'm taking a huge risk here by using the example that i'm about to share with you; please DO NOT think for ONE SECOND that you are being ACCUSED of anything, ok? i'm using this example because i believe it will get through to you with enough clarity. i DO NOT want to hear ANYONE say "god almighty, did he _really_ just accuse us of being horrible people by association", ok? do you know what the world's most authoritative medical texts are on the subject of pain? pain thresholds, tolerance, stress levels and so on? it's the documentation that the nazis made during their reign. horrifyingly, they were *genuinely curious*, but, unlike other groups who have tortured other humans, they meticulously documented all of their work. why am i mentioning this example? because, *technically*, the nazis documentation of their work is sufficiently flawless as to be of extremely high *technical* value in the medical world, even today. ... but does that mean that *strategically* they should even have been doing that research in the first place? does the *technical* quality of their work justify their torturing and murdering of other human beings, just to see what happened?? of *course* it f*g well doesn't! so this extreme example should, i believe, serve as an extremely graphic illustration that, in any group, technical decisions need to be guided by some sort of moral and/or strategic compass. not that i claim to be an authority on either [1]. would you agree with that? i mean the moral and strategic compass bit, not my claim to not be an authority on moral compasses :) l. [1] please don't say i am claiming to tell you what to do, therefore you have the right to ignore it. as a group you keep doing that, and i keep having to tell you i'm not, and it's getting really, really old. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/capweedyrutzfv9wu2pouktngl6ckbdoisetqgla-etdzyi1...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett wrote:
> So, please go educate yourself on what libsystemd0 actually does,
i know what it does, and what it does - technically - is *not* the
issue that i am concerned about.
> and if
> for some reason you still consider it a problem after doing so, you'll
> need to explain why,
i have done so, a number of times. take away the name of the
library. take away what it does. take away how it does it, because
none of those things are relevant.
what *does* concern me is that it takes such incredible (and amazing)
efforts by people like adam for the average end-user or sysadmin to
contemplate replacing {insert nameless package}.
that *is* the problem. i'm aware that there are many people in key
positions in debian who do not see this lack of choice as being the
problem, but i can assure you that it is.
> because as demonstrated in this thread, even those
> developers in Debian who still do care about non-systemd systems do not
> agree with you that it's a problem. See, for instance, Russ's response,
> which you lauded while failing to actually comprehend, since you seem to
> believe that his response described something that needed changing
> rather than describing the current state.
i believe tiredness may be affecting my ability to understand the
point you're trying to make, here. i'm genuinely pleased that russ
(and adam) came up with the same possible solution (dynamic library
loading) that, if deployed, would end this entire issue because it
would allow people to make a choice.
ah. i got it. i worked it out. the sentence that bothered me was
the one which implied that no change is possible. or desirable. i
leave it to you over the next few weeks and months to assess whether
that assertion is true or not: when people continue, over the next few
weeks and months to *not* stop talking about systemd, remember this
moment, yeah?
> We used to build a half-dozen versions of libsdl, with support for
> various libraries, just so that people could avoid installing unused
> libraries on their systems. We don't do that anymore; if you install a
> program based on libsdl, you'll get libsdl1.2debian, which depends on
> libasound2 and libpulse0 and libdirectfb-1.2-9 and libx11-6 and other
> libraries. If you always run against X with ALSA, and never run with
> DirectFB or PulseAudio, then you get a couple of extra libraries on your
> system. Worth it so that libsdl doesn't have to build a half-dozen
> conflicting binary packages.
great! sounds like a sensible decision to me.
question. is libsdl on a par with sysvinit, openrc, systemd and
depinit? no it isn't, is it. if you run a server, do you *really*
need libsdl? no you don't, do you.
and, y'know what: another thing - the very fact that there *is*
choice within libsdl - a lot of it - different backends, different
graphics, different sound libraries, that's... that's fantastic!
... because it's everything that systemd is not.
right now, my deepest concern is that there isn't any other choice.
do you not also perceive that as being a problem?
> You should also learn what the word "unilateral" means; for someone
> willing to pedantically post a link to a dictionary, you seem to have
> failed to read it. Distributions and projects have independently (or,
> if you like, *multilaterally*) started using systemd because it works
> well for them.
yyyeah... i know - because they all took what the upstream developers
provided and they all ripped out everything *but* systemd.
and that means we're into a monoculture.
do you see that that is a problem? to make it clear: under what
circumstances has a monoculture traditionally and historicallybeen a
problem, under software-related (and non-software-related)
circumstances?
> And yes, that means they use libsystemd0, whether or not
> they depend on PID 1 at runtime. Your incredulity at how that managed
> to happen does not actually refute that it did.
i never said that it did, nor was i incredulous at how it happened.
i believe i've posted a number of times - twice on this list -
indicating that i have been keeping an eye on this for some time, and
also analysed retrospectively what happened. *at no time* did i post
any kind of unrealistic statements "how did that happen??" i can see
very clearly how it happened, and, importantly - twice at least - i've
gone to some lengths to say that i don't consider it to be anyone's
fault.
... where on earth are you getting this stuff about "how incredulous
i am" from, josh? :) *puzzled and tired*...
l.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/capweedxmemkdlgrfzng2oa0sibfawl2rrtp261avbyx40xu...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
On Tue, Feb 17, 2015 at 6:25 PM, Luke Kenneth Casson Leighton wrote: > which should help answer the question you asked: your work - fantastic > as it is - was *impossible to find*. it doesn't even remotely come up > on the radar of queries. *nobody knows what you've achieved* and > that's something i would like to help correct. ok done: http://neofutur.net/systemd-vault also i've edited http://without-systemd.org/wiki/index.php/Main_Page adding a sentence that, i hope, allows what you did, adam, to be easily distinguished from all the "forks" and rather challenging alternatives to consider (including the inconvenience of moving away from debian entirely). l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/capweedzscrh+mfp93+4xgkh2klbpxewmzfiizqpnpv7y5o+...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
On Tue, Feb 17, 2015 at 7:03 PM, Andrew Shadura wrote: > Hello, > > I'd like to apologise for my mail I sent about two hours ago. I have > overreacted mainly because of the length of the email, CAPS INSIDE and > also because it's a topic which is being discussed for more than a year > and which many of people here are already tired of. i know, andrew. i've been following it from a distance, staying away until i had a better handle on what's going on, and a clue about possible solutions. i'm writing to the systemd developers now. > > I however still think that such lengthy writeups do really belong > somewhere else, maybe to a blog, with a short post with a link being > posted here. yehh, i wasn't expecting it to be that long - i lost track of time, but also i wanted to make sure i addressed and included everyone who responded over the past couple of days. > Luke, Claude and everyone else, I am really sorry. not a problem andrew. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPweEDyfnUwFTD2dde36DM2Ay2jQVv=pfsoozqqmo7_n_mc...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
adam, i apologise for not being in a position to reply in-thread: as mentioned previously i tried (via gmane) but the entire discussion is completely missing, and i forgot to ask people in the original post to cc me if they would like an ongoing threaded reply. i also notice that you removed debian-user, so for those people on that list who (like me) were completely unaware of the fantastic work that you've done, here is a link to the archives containing what you wrote: https://lists.debian.org/debian-devel/2015/02/msg00189.html all i can say is, HOORAY! and thank you for doing properly what i only hinted at was possible. i wish i had known of what you've done, even a few days ago. i would have: (a) not have had to mess up my system (b) would not have written the slashdot report (c) would not have heard from so many people who have put links to my report onto their site (d) not been in a position to further advocate your fantastic work (to them) so... actually.. if you think about it, it's a good thing. if you don't mind i'm going to contact several people who maintain web sites and lists in order to have them add your work to them. which should help answer the question you asked: your work - fantastic as it is - was *impossible to find*. it doesn't even remotely come up on the radar of queries. *nobody knows what you've achieved* and that's something i would like to help correct. now, exactly as you, i and russ point out, the next phase is to do dynamic library loading. i'm absolutely delighted to note that you have a handle on this, already, and i see you make it clear that you've thought it through already. i plan to write directly to the systemd developers, taking at face value the recent announcement that they listen to users. is there anything that you would recommend in particular that i include? well done, and thank you for making my hacks completely irrelevant in under 24 hours. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/capweedwatrhrmtivzii369dk2wvx6kdrfodnzj7ek99mbht...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
On Tue, Feb 17, 2015 at 5:58 PM, Andrew Shadura wrote: > Hi, > > On 17 February 2015 at 18:20, claude juif wrote: >> Really rude answer. Really bad. > > I find it really rude to send emails of about 300 lines of text in > total. Extremely rude. i did apologise in advance, and explained why i took the steps that i did,. if you are unable to accept that apology, i cannot help you with that, andrew (as in: i recognise that i have no right to interfere with your choice of mindset): it is your decision to choose what to think and what to react to (positively or otherwise), and i have to respect that. however as this is a public forum for discussing debian, and there are thousands of people reading this and many more in the future, apart from apologising for taking up so much time in distractions of this kind i am not going to get involved further into discussions of ettiquette, if that's ok. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPweEDxKaorP=84ztkzrakptawngboy4_9ry7hg_7jwhnss...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
On Tue, Feb 17, 2015 at 5:20 PM, claude juif wrote: > > > 2015-02-17 17:55 GMT+01:00 Andrew Shadura : >> >> Hi Luke, >> >> On 17 February 2015 at 17:28, Luke Kenneth Casson Leighton >> wrote: >> > <265 lines of text and counting snipped> >> >> In short, this is TL;DR. We've all got better things to waste our time >> on. Please go away. Nobody's interested in this any longer regardless >> of their position on systemd. >> >> Thanks. > > > Hi, > > Really rude answer. Really bad. thanks for pointing that out, claude - it helps that it was someone else who pointed out that being uncivil by asking a *person* to go away doesn't make the *problem* go away. andrew: i will go away only when i am satisified that the problem which i believe it is my duty and responsibility to help highlight and fix has, in fact gone away. if you feel that this is sufficiently beyond your psyche's limits, there are a number of ways in which you may deal with that, but *demanding* of people that they violate their principles, as well as inconveniencing many other people and increasing _their_ stress levels by voicing such demands... can you see how that that really will not work out very well, for everyone involved, including yourself? short answer: no, i will not accede to your unreasonable demand. i have the right to speak up, and, just to make it clear: like that famous person said, which i find myself quoting within a couple of hours for completely different reasons, "i do not agree with you, but i will defend your right to say so". so thank you for making it clear that you find this difficult to cope with, but please do take a relaxing holiday or something, ok? :) anyway, in other news, i'm delighted to have been made aware (very recently) of the work by adam borowski, which i have to say is completely unknown and underappreciated at this point. links are here: http://forums.debian.net/viewtopic.php?f=20&t=119836 it would appear that one person has managed to achieve what the devuan team are endeavouring to duplicate, and what my report has only begun to scratch the surface on. i find this to be incredibly funny. *but*... we are *not done yet*. the work by adam is amazing and everything that i was hoping would be done as an interim measure, so adam THANK YOU, you have made it possible for the average end-user and sysadmin to continue to manage their machines in a convenient way *and* still make the choice to not have libsystemd0 present, and that's just... words fail me to express my gratitude. *but*... the next phase is to tackle upstream and to pursue the design concept advocated by russ: dynamic loading. there really should be no need to use what adam's done (or what devuan want). it *really should* be possible to install (or remove) a few packages that are *part of debian*, and have libsystemd0 enabled or disabled *at will*. even with editing an /etc/ config file. that this is not even possible *is* why i will not stop - andrew - until it is. have i made myself clear? l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPweEDxC+vvKuUd5sORghK1FX1NPhw-n97zHZsT21RCgkujM=q...@mail.gmail.com
Re: how to remove libsystemd0 from a live-running debian desktop system
ok, so there's been quite a discussion, both on slashdot, where amazingly the comments that filtered to the top were insightful and respectful, and also here on debian-devel and debian-users. as i normally use gmane to reply (and maintain and respect threads) but this discussion is not *on* gmane, i apologise for having to write a summary-style follow-up: if people would like me to reply (thank you christian) please cc me in future, but (see last paragraph) i think the software libre community's interests are best served if i wait for replies to accumulate for a few days. after thinking about this yesterday, a random sentence popped into my head, which i believe is very appropriate: "i disagree with what you are saying, but i will defend your right to say it". i believe it was someone famous who wrote that, and it applies to this situation because this really isn't about the technical merits of the available software: solutions will come in time (and already are: eudev, mdev, uselessd and many more). the reason why i've joined this debate is because i feel that closing doors on choice in ways that force people to have to make extremely disruptive and risky decisions that could adversely affect their livelihoods - i have a *really* bad feeling about that, and i cannot sit by and let it happen without speaking up. in the past two days i've seen a lot of people on this list make it clear (by saying for example "you have the source, go modify it") that they do not truly appreciate the responsibility and duty of care that they have. in saying that i can say that *i know* how you feel: i've been the leader of many software libre projects where people would expect me to feed them answers for no financial reward - and all those other nuances that we frequently encounter. but i learned in the past few years that even if you are not being paid, you *still* have a duty to those people less intelligent or with less time or less money than you. we're *serving others* with our skill, time and intelligence. it's a really awkward and delicate situation, i know, but answering "go away and modify the source yourself" is to do both yourself and the recipient of that answer a very strong disservice. anyway - down to it. so, marco, you wrote: > Again, you clearly do not understand well how systemd works. marco: understanding or otherwise how systemd works is not the point: the point is that there has been a unilateral decision across virtually every single GNU/Linux distro to abandon and remove *any* alternative to having libsystemd0 installed. historical precedent in the software industry and beyond tells us that placing so much power and trust in a single system and a single group should be ringing alarm bells so loudly in your head that you should wake up deaf after having first passed out with dizziness! :) so could i ask you, as i really genuinely don't understand, why is it that the lack of choice here *doesn't* bother you? i'm not asking for a technical review or a technically-based argument as to "why libsystemd0 is better" - that has been debated many many times and is entirely moot. i'm asking "why does *only* having libsystemd0 as the sole exclusive startup method, removal of which prevents and prohibits the use of a whopping FIFTEEN PERCENT of the available debian software base, and where that exclusive exclusionary process is being rapidly duplicated across virtually every single GNU/Linux distribution that we know; why does that *not* make you pause for thought that there might be something desperately and very badly wrong?" ric writes, amongst other things: > You are completely free to fork or go your own direction, indeed we are, and in fact one person mentions further in the thread so far that they did exactly that. they also outline quite how much work it is. on the slashdot discussion, someone pointed out that it was really unconscionable that people have to go to such extreme lengths. GNU/Linux distros should be a place where people can make happy and convenient choices, not extreme decisions! the extreme absurd version of what you suggest is to do what very very few people in the world have ever done (one of them being richard lightman, an amazingly intelligent and reclusive individual), namely to create an *entire* linux distribution - on their own - from source. i take it you can see, from that example, quite how much of a disservice it is to say what you said, ric? no, the very fact that this *doesn't go away* - that discussions about libsystemd0 are *continuous and ongoing*, should tell you that there is something very, very badly wrong with what's going on. and that's what i want to get to the bottom of. like... *properly* understand. the second thing, ric, is that i have to point out, respectfully, that there are signs that you didn't read the slashdot article summary, nor my report, as shown here: > But, to raise comparisons to MicroSoft is very much out of line. t
Re: how to remove libsystemd0 from a live-running debian desktop system
On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler wrote: > Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton: >> >> http://lkcl.net/reports/removing_systemd_from_debian/ > > > It's funny that when Wheezy (not Jessie!) came out, nobody complained > that libsystemd-login0 (which is now part of libsystemd0) was as a > dependency of dbus, so it is probably already installed on most desktop > systems running current Debian stable. i'll hazard a guess that it's because they had no idea that, in the very near future, all the major desktop developers and all the major distros would make the unilateral decision to hard-code the *exclusive* use of systemd (or parts of it). my assessment is that it's that total lack of choice that is causing people to get so upset. but there's no need to get upset about it: *we didn't know*. nobody could have predicted how far this would go, so quickly. so the question then becomes: at a fundamental level (in a distro-agnostic way) how to go about giving people a proper choice (to run systemd and associated components, or not)? l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPweEDwgsC9nfXfiGnTPuXS9SdJNExqaXhLgdQdPpJ9g=7g...@mail.gmail.com
how to remove libsystemd0 from a live-running debian desktop system
http://lkcl.net/reports/removing_systemd_from_debian/ i've documented the process by which it is possible to run some of the debian desktop window managers (TDE, fvwm, twm etc.) without the need for systemd or libsystemd0 or any components related to systemd whatsoever. the process is not without difficulties, however out of (at the time of writing) only two people who have followed this procedure, i was the one that ended up having to disable udev: the other individual had a working system (devoid of libsystemd0) purely by following only the instructions to alter and replace bsdutils from the util-linux package. the reasons for demonstrating that this is possible have absolutely nothing to do with my *personal* (technically-based) dislike of systemd, although my reasons for actually removing libsystemd0 from personal systems *are* based on a technical assessment (mostly with a sysadmin eye). but, i repeat: my *personal* choice has *nothing to do* with the reason for posting this documentation. the reason for demonstrating that this is possible is because nobody has yet made it clear to either the upstream developers - or to the distro maintainers who unfortunately are caught in the crossfire - that systemd's unilateral adoption is fast becoming an "all-or-nothing" polarised choice that reminds me keenly of the polarised Microsoft Monopoly power and dominance of the late 1990s. and that *really is it*. the technical issues are completely irrelevant: those can and will be solved. already we have evdev, mdev, devuan, uselessd and many more, but those technical options are *COMPLETELY SHUT OUT* by the exclusive - monopolistic - position that systemd now has. to illustrate the dominance of libsystemd0, if you carry out an "apt-get --purge remove libsystemd0", *all* of the packages and many more on the following PNG will be removed: http://anfo.slavino.sk/libsystemd-journal0.png that list is woefully incomplete, so i have generated a current list using apt-rdepends -r libsystemd0 | some manual magic | sort | uniq. http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt the list is a whopping 4,583 packages (from the current debian/testing). apache2-dev, androidsdk, apt-cacher-ng, avahi-daemon, blender, bluetooth, bochs, cairo-dock, calligra, consolekit, cups-daemon, cups-core-drivers, cups-driver-gutenprint, dbus - this is just a few major software libre packages i can see in the the first 9% of the list that are affected (cannot be installed) should anyone exercise their right to choose *not* to have libsystemd0 on their machines. even dh is on the list. erlang is on the list! kde, gimp, xfce, lxde, gnome, libreoffice, xine, mediawiki, mplayer, network-manager, openjdk-7, phonon, php (??? why is php dependent on libsystemd0??), pidgin, policykit-1, postfixadmin (??), pulseaudio, qemu, syslog-ng, vlc, wicd (client and server), xbase-clients (??), x11-apps (??), xbmc, xchat... those are just ones that i recognise out of the 4,500+ packages that are not permitted to be installed. so the short and long of it is: i do not like it when people are not given the freedom to choose... and that includes when, just like when microsoft was so dominant in the 1990s, the choices they are presented are not really a choice at all. what i have done therefore is to show how to modify the debian packages for policykit-1, dbus, pulseaudio and util-linux, such that libsystemd0 may be entirely removed. removal of libsystemd0 from those packages trims that list of several thousand unilaterally-excluded packages *significantly*. this process comes with a price: i had to disable udev, and i had to re-enable the keyboard and mouse sections in xorg.conf that i had added years ago. however, already within hours of the report's publication i have received word from one other person who did *not* have the same extensive difficulties that i encountered: udev (unmodified) worked perfectly for them. in a follow-up message they did however explain that they have successfully installed and then removed (at an earlier point) a source-compiled version of mdev, which illustrates that they have some quite significant experience in maintaining a hybrid of standard debian packages and system-critical packages compiled directly from source. so, in short, i have two key things to say. to debian-users: you don't have complete choice (yet), but i have demonstrated with a few hours work that there is a way to run (certain) desktop environments without requiring libsystemd0 or any of its dependencies, and after a little investigation there do appear to be people working hard to give you your right to choose what software to run *without* having to abandon debian. to debian-developers: the technical issues are irrelevant (and can always be solved over time) - it's that you are complicit in removing people's software freedom right to choose what to run on their system: that is why so many users
closing 760906
close 760906 thanks Silly me, this is already packaged :) -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 signature.asc Description: Digital signature
Bug#760906: ITP: speedtest-cli -- test Internet bandwidth from the console
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: speedtest-cli Version : 0.3.1 Upstream Author : Matt Martz * URL : https://github.com/sivel/speedtest-cli * License : Apache-2.0 Programming Lang: Python Description : command-line interface for testing Internet bandwidt Utility that allows for testing a host's speed against various nearby servers. This makes use of the Speedtest.net's network of speed testing servers, distributed around the world. Speedtest.net is a commerical service offered by Ookla, Inc. However, this software could be extended to support other servers that implemented the same protocol. -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 signature.asc Description: Digital signature
Luke Helmond Music Soundcloud
https://soundcloud.com/luke-helmond Check my music == Unsubscribe debian-devel@lists.debian.org from this list: http://lukehelmond.us8.list-manage.com/unsubscribe?u=3c4e3acca2485b5f3f655fde4&id=40426c7452&e=305875a5cb&c=d751629945 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3c4e3acca2485b5f3f655fde4305875a5cb.20140806012...@mail179.us4.mcsv.net
Luke Helmond Demos
Dear i'm writing to you because i want to let you hear my music.I'm searching a great label to sell my music.Hope you are the right choice for my music carrier. Hope to hear soon from you Best Regards Luke Helmond http://www.lukehelmond.com Track private link: https://soundcloud.com/luke-helmond/move-away-1-luke-helmond https://soundcloud.com/luke-helmond/nebulamaster-finale https://soundcloud.com/luke-helmond/leonida https://soundcloud.com/luke-helmond/i-love-u-dear-oscillator https://soundcloud.com/luke-helmond/serendipity-luke-helmond-3 Youtube Video Link: https://www.youtube.com/watch?v=0Cm9pyf2quE == Unsubscribe debian-devel@lists.debian.org from this list: http://lukehelmond.us8.list-manage.com/unsubscribe?u=3c4e3acca2485b5f3f655fde4&id=40426c7452&e=305875a5cb&c=28bd35c61b -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3c4e3acca2485b5f3f655fde4305875a5cb.20140805202...@mail160.atl81.rsgsv.net
Sony Music
Good morning,here is my free download music https://www.facebook.com/pages/Luke-Helmond/189702991126547?ref=hl Best Luke Helmond lukehelm...@gmail.com == Unsubscribe debian-devel@lists.debian.org from this list: http://lukehelmond.us8.list-manage.com/unsubscribe?u=3c4e3acca2485b5f3f655fde4&id=40426c7452&e=305875a5cb&c=e733d562f9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3c4e3acca2485b5f3f655fde4305875a5cb.20140805201...@mail167.atl21.rsgsv.net
Re: arm64 update - help wanted
On Thu, May 15, 2014 at 2:10 AM, Wookey wrote: > The debian-port arm64 rebootstrap is progressing nicely, and we just > passed 4200 source packages built, with another few hundred > pending. There are now 2 buildds running. awesome > Thus I'd love it if anyone else could help go through the failures > pile and file bugs, or upload old existing ones, or classify them on > the wiki. Or if they happen to be your packages then just fix them :-) > > I've put some links on the wiki page > https://wiki.debian.org/Arm64Port#Bug_tracking suggestion, wookey: i'd love to help... but obviously with no hardware that's kinda hard: is there a clear set of instructions somewhere - a wiki page for example - on how to debootstrap an arm64 qemu so that even if it's dead slow it's still possible to help out? l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPweEDyrR8woYLt3i=DLkyf3e-K=c=8ddhcjcwe2liwqxgh...@mail.gmail.com
Re: arm64 update - help wanted
> suggestion, wookey: i'd love to help... but obviously with no > hardware that's kinda hard: is there a clear set of instructions > somewhere - a wiki page for example - on how to debootstrap an arm64 > qemu so that even if it's dead slow it's still possible to help out? https://wiki.debian.org/Arm64Qemu wookey i found this - it's not entirely clear (lots of options, not step-by-step): what is relevant to getting up and running, is the page still relevant, has aarm64 made it into the latest debian qemu package yet. tia, l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/capweedxywtwrtxi7qgevefku3rgxn-syh3iu5fukxj2twyc...@mail.gmail.com
Bug#731880: ITP: python-apns-client -- Client for the Apple Push Notification Service
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: python-apns-client Version : 0.1.8 Upstream Author : Sardar Yumatov * URL : https://bitbucket.org/sardarnl/apns-client/ * License : Apache 2.0 Programming Lang: Python Description : Client for the Apple Push Notification Service This package allows integration with Apple Push Notification Service, a push notification service offered by Apple for use on its iOS devices. It provides similar functionality to python-gcm-client, which implements Google's protocol for Android. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131210191428.6262.56215.report...@cobalt.mit.edu
Bug#731879: ITP: python-gcm-client -- Client for Google Cloud Messaging
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: python-gcm-client Version : 0.1.4 Upstream Author : Sardar Yumatov * URL : https://bitbucket.org/sardarnl/gcm-client/ * License : Apache-2.0 Programming Lang: Python Description : Client for Google Cloud Messaging This package allows integration with Google Cloud Messaging, a push notification service offered by Google for use on its Android devices. It provides similar functionality to python-apns-client, which implements Apple's protocol for iOS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131210190531.4671.33816.report...@cobalt.mit.edu
Bug#721731: ITP: camo -- SSL image proxy to prevent mixed-content warnings
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: camo Version : 1.1.1 Upstream Author : Rick Olson and Cory Donohoe * URL : https://github.com/atmos/camo * License : Expat Programming Lang: JavaScript (nodejs) Description : SSL image proxy to prevent mixed-content warnings Camo is all about making insecure assets look secure. This is an SSL image proxy to prevent mixed content warnings on secure pages. Using a shared key, proxy URLs are encrypted with hmac so we can bust caches/ban/rate limit if needed. Features include: * Proxy Google charts * Proxy images under 5 MB * Follow redirects to a configurable depth * Proxy remote images with a content-type of image/* * Disallows proxying to private IP ranges -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130903160256.18529.9753.report...@cobalt.mit.edu
Re: Bug#719556: ITP: logcat-color -- a colorful alternative to "adb logcat"
On Tue, 2013-08-13 at 08:45 +0200, Bastian Blank wrote: > On Mon, Aug 12, 2013 at 11:14:14PM -0400, Luke Faraone wrote: > > This package is designed to be used in conjunction with the Android > > "adb" utility to view logs on an Android device or emulator. > > Why does it not mention this in the package name? And is there a reason > not to publish this in the adb package itself if it is that useful? It is a separate project from the upstream Android project; it "Enhances: android-tools-adb" and will even work without ADB installed to colourise log files. Compare "tig". Cheers, Luke signature.asc Description: This is a digitally signed message part
Bug#719556: ITP: logcat-color -- a colorful alternative to "adb logcat"
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: logcat-color Version : 0.5 Upstream Author : Marshall Culpepper * URL : https://github.com/marshall/logcat-color * License : Apache-2.0 Programming Lang: Python Description : a colorful alternative to "adb logcat" This package is designed to be used in conjunction with the Android "adb" utility to view logs on an Android device or emulator. logcat-color is highly configurable and is compatible with upstream logcat's command-line flags. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130813031414.19705.12180.report...@cobalt.mit.edu
Bug#705758: ITP: statsd -- Stats aggregation daemon
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: statsd Version : 0.6.0 Upstream Author : Etsy * URL : https://github.com/etsy/statsd * License : Expat Programming Lang: Javascript (node.js) Description : Stats aggregation daemon StatsD is a network daemon that runs on the Node.js platform, listens for statistics, like counters and timers, sent over UDP, and sends aggregates to one or more pluggable backend services. The project was started by Etsy after a similarly-named project at Flickr. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419151644.30700.1919.report...@cobalt.mit.edu
Bug#705691: ITP: defusedxml -- XML bomb protection for Python stdlib modules
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: defusedxml Version : 0.4.1 Upstream Author : Christian Heimes * URL : https://pypi.python.org/pypi/defusedxml * License : Python Programming Lang: Python Description : XML bomb protection for Python stdlib modules The results of an attack on a vulnerable XML library can be fairly dramatic. With just a few hundred bytes of XML data an attacker can occupy several gigabytes of memory within seconds. An attacker can also keep CPUs busy for a long time with a small to medium size request. This library allows for XML to be parsed in a manner that avoids these pitfalls. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418154619.27128.72164.report...@cobalt.mit.edu
Bug#702464: ITP: python-django-bitfield -- Django module implementing BitFields
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: python-django-bitfield Version : 1.6.4 Upstream Author : DISQUS * URL : http://github.com/disqus/django-bitfield * License : Apache 2.0 Programming Lang: Python Description : Django module implementing BitFields django-bitfield provides a custom field which allows various bits to be stored inside one fixed-width BigIntegerField. The custom field provides syntatic sugar for accessing those flags easily from a Django application. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130306213838.7670.71133.report...@cobalt.mit.edu
Re: Gentoo guys starting a fork of udev
Roger Leigh codelibre.net> writes: > If you want a reliable system, you need a reliable PID 1. yes. this was i believe why richard lightman implemented depinit in i think it was under 1,000 lines of code. he was delighted when i came up with a simple modification which would allow him to remove a further block of that, out-sourcing the job to a shell script and increasing the flexibility at the same time. unfortunately i haven't heard from richard since 2008. he's gone even more reclusive than he was before i met him. which is a pity. we need more people in the world with his level of quiet genius. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20121117t062915-...@post.gmane.org
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane wrote: > Hi, > > On Thu, 19 Jul 2012 18:35:44 +0100 > Steve McIntyre wrote: >> buildds >> === >> >> Both armel and armhf are doing well, covering ~96% of the archive. We >> don't have any ARM server hardware yet, so we're stuck using >> development boards as build machines. They work, but they're a PITA >> for hosting and they're not designed for 24x7 usage like we're doing >> so they're not that reliable. > > As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. > It has 2GB RAM, reliable production use and we can buy it NOW. > > *) http://lists.debian.org/debian-arm/2012/07/msg7.html hideki, those look superb. summarising (in case anyone's missed it): they're armv7 compatible because they're using a marvell xp processor; they're up to dual-core 1.4ghz and the company openblocks can do them with up to 3gb of RAM, and i gather the openblocks boxes have a mini pci-e port as well as gigabit ethernet. i'm including arm-netbooks because there may almost certainly be people on that list who would be interested in a group buy. there has been quite a bit of interest in getting hold of modular computing devices for rack-mounted server usage. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDxB=akchpidonavwvuon9xf0gge9cf2smyjrrgdm3+...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 9:15 PM, Adam D. Barratt wrote: > On Thu, 2012-07-19 at 20:09 +0100, Luke Kenneth Casson Leighton wrote: >> On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre wrote: >> > Both armel and armhf are doing well, covering ~96% of the archive. We > [...] >> (*1) and if someone _really_ wants a debug build of that particular >> problematic package, on a build and distro port that's still >> experimental, well, surely they can compile it themselves, using their >> own resources, yes? > > Neither wheezy nor the armhf port contained in it are experimental. If > that's not what you meant, please be clearer. yes i used the wrong word: apologies. i was trying to convey the following in a concise way, and chose the word "experimental", which i realise in hindsight doesn't cover half of it: "doesn't yet have as many users as e.g. i386/amd64, hasn't been around as long as i386/amd64, hasn't got hardware that the average user can buy at a spec approaching that of i386/amd64 yet, and doesn't have as many packages successfully and reliably building as i386/amd64". btw continuing on the thread on debian-arm (only) i put forward a [temporary!] procedure for review which is an interactive balancing act to relieve the burden of having excessive linker-related loads, moving it down instead to later inconvenience for users. of course, if the package is "perfect" and there *aren't* any bugreports then the interim proposed procedure has done its job. http://lists.debian.org/debian-arm/2012/07/msg00073.html l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDxPpxZsPjHf7R=nzem5jibfa1snjsve5hk-b167xqu...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre wrote: > Both armel and armhf are doing well, covering ~96% of the archive. We > don't have any ARM server hardware yet, so we're stuck using > development boards as build machines. They work, but they're a PITA > for hosting and they're not designed for 24x7 usage like we're doing > so they're not that reliable. there was a post on the arm-netbook mailing list about a 7W quad-core tegra3-based mini ITX motherboard which could take up to 2gb of RAM. whether it's the usual "let's-put-something-out-there-see-if-anyone-is-actually-interested" style of vapourware or actual reality i'd strongly suggest someone gets onto them and considers putting together a group buy / bulk order just to make it worthwhile their time making a batch, because it's literally the first ARM-based machine i've ever heard about that can actually take 2gb of RAM. oh: also the motherboards have eSATA and uPCI-e, hm let me find the post here you go: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html btw, steve: it's not the c++ doing linking in swap that's the problem, it's trying to do *debug* builds of c++ applications that's the problem. webkit for example requires a minimum of 1.4gb of resident RAM for the linker phase if you enable debug builds. i have mentioned a number of times that it's debug builds that are the problem, and that all you have to do is disable debugging (*1) and the build will complete within 15 minutes instead of 15 hours, but as usual because it's that "fucking moron lkcl telling us what the fuck to do" nobody bothers to listen. well, keep on not listening for as long as you (plural) find it useful to do so: i'm not the one with a PITA for having to wait 18 hours for a debug build of a c++ app to complete, am i, eh? *eyebrows-arched* l. (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDzD1sVfWTUFrt64=drral2fntoagjaqmm8oabyag7d...@mail.gmail.com
Re: gnome is completely f^Mmessed up
On Fri, 8 Jun 2012 16:15:42 +0900
Norbert Preining wrote:
> Hi everyone,
>
> is this only me or do I have the feeling that we are going down
> the trench with Gnome?
> Repeatedly:
> - first login: nautilus segfaults in libnautilus-fileroller.so
> after log out and log in it sometimes works
> starting it manually most of the times work, but not always
> - ssh/gpg agent: most of the time just is completely useless
> either does not ask, or just segfaults in libglib-2.0
> - plugging/unplugging power cord makes gnome-shell crash (known bug)
> - ...
> When I finally manage to get a running session, then out of nothing
> the blue whale appear, BSOD.
>
> Is this a joke? Are we going to release that in June/July/whenever?
>
> Best wishes
>
> Norbert
>
> Norbert Preiningpreining@{jaist.ac.jp, logic.at,
> debian.org} JAIST, Japan TeX Live &
> Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0
> D2BF 4AA3 09C5 B094
>
> PEEBLES (pl.n.) Small, carefully rolled pellets of skegness (q.v.)
> --- Douglas Adams, The Meaning of Liff
>
>
I have the added issue that GNOME seems to (somehow) manage to spawn in
excess of 100 Xserver when I try to log in.
I switched to XFCE4 as well.
~ Luke Cycon
DM -- University of California, San Diego CS Undergrad
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120610135404.72fcf...@lukelaptop.home.local
Re: summer of code 2013 proposal
Hi Henri, On 24/03/12 06:29, Henri Le Foll wrote: > A Team field should be added to debian/control. (and also to the .dsc) > === > >- I hope every package will one day belong to a team. > >- I think that each package in wnpp or rfa or rfh should belong to a > team (other than QA). If I need help on my package, why should it belong to a team when I file a RFH? >- Some information about the difficulty to maintain the package can > be automacally extracted from the source package and added to the dsc file. That's something that is incredibly subjective, bound to change as things arise, and of limited utility. A package in Perl might be more difficult for someone who only has Python experience, for example. > I am wrong in saying that information like : > >- a source package generates only one binary package > >- debian/rules is trivial. Tomorrow upstream could add a new feature which requires you to write all sorts of custom rules. > Three or more characters which could easily show the difficulty to > maintain the package. > AA0 for simple ones. > […] So I'd need a table to decipher the package difficulty? > B : only one file like copyright or control need attention What does this mean? -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 signature.asc Description: OpenPGP digital signature
Re: Bug#631139: mosh ITP not done, just package name taken over
On 25/03/12 16:31, Christoph Egger wrote: > Hi! > > Christine Spang writes: >> I'll talk to David and sponsor his upload if we can agree on an >> alternate name. > > Make sure to also get the binary renamed (though the scheme one is used > in shebangs since nearlly half a decade). If its been used in scripts for nearly half a decade, and its not in Debian already, it sounds like the user base which would be sad for a rename would be low. Anyway, if those scripts were running on Debian systems, then they probably should be referencing /usr/local/bin if mosh (scheme) was custom-installed. Therefore a transition to a debian-provided package would need changes already. -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 signature.asc Description: OpenPGP digital signature
B2G security model (debian package management recommended) - help and advice needed
folks, hi, please take a deep breath before reading. i'm keenly aware of the view that many people hold of me in debian. that i'm even bringing something to your attention and asking for your help (not for me, personally) should therefore tell you a lot more than needs to actually be said. i'm presently coming up to nine hours of continuous non-stop typing (just today) to deal with something on the B2G developer mailing lists: the security model, and it's getting to the point where i'm i serious need of some highly-technical (as well as social) assistance. your patience greatly appreciated whilst i explain. B2G is a new operating system where the Gecko web front-end doubles up (triples up?) as the window manager as well as the applications "runner". they started from the android codebase, ripped out java, ripped out webkit, dropped gecko in place using OpenGL _directly_ writing to the framebuffer, and then went, "ok, now we got the basics, let's make this work". as a concept, i find this both fascinating and exciting. the resources of the mozilla foundation with the non-profit-orientated motivation to create an open alternative to google's android? fantastic! by the time they're done, there will be *another* FOSS operating system out there - one with the potential to reach a hundred million units or more, through mass-volume sales world-wide, via numerous telephone companies. applications could be developed by people that could take off just as fast as any android or iphone application: potentially millions of downloads per day if an app becomes highly popular. and the whole thing *won't* be tied to a particular vendor, or to a profit-maximising company. the mozilla foundation is a non-for-profit organisation, so has the potential to take into consideration aspects that are *not* over-ridden by profit maximisation (such as "increasing revenue stream"). i have every confidence in the mozilla foundation to deliver the goods on the U.I, on the apps example development, and much more besides. what's of fundamental and deep concern to me is their ability to comprehend the security implications of what they're doing. and, you *know* me - it should come as absolutely no surprise to any of you to learn that even the mozilla foundation is deploying increasingly-hostile censorship measures to prevent me from communicating with them. ok, you can laugh now. go on. yeah, i know. i did it again. happy now? :) but seriously: it should be reasonably clear as to why i've persisted with this *despite* increasing resistance, and it should speak volumes that i'm asking (requesting NOT demanding) - publicly - for people to wander over and take (CONSIDER taking) a look at the security discussion taking place. why am i asking [requesting-not-demanding] that _you_ - debian developers - get [CONSIDER getting] involved? it's because the application distribution model that i know best (that will also fulfil the requirements) is... yep, debian. why i am so deeply concerned about the discussion on the b2g-dev mailing list has nothing to do with me, but has everything to do with what the people in the mozilla foundation - those actively involved in the b2g decision-making process - are recommending be used for application distribution. it's SSL! now, i know you know how debian package management works. imagine if someone on a debian list somewhere went "hey guys! you know that infrastructure you use to distribute debian packages? i've got a great idea for a replacement for the system you've been establishing and refining for almost 20 years, it's called SSL!" now that you've picked yourself up off the floor, either from shock or from laughing so hard you couldn't stand upright, you may be wondering if i've made some sort of hilarious techie joke. i assure you i haven't. what _would_ be funny though would be if, after reading this, someone who *really* knows how SSL well and truly works actually said "yes, here's a workable technical solution which uses SSL and delivers the goods, i did a complete paper on it, it easily scales to the numbers you describe, but didn't mention it here on the debian lists ever because they already have a fully-working solution, and i didn't wish to make an ass of myself like you do on a regular basis, mr lkcl". then i would be very very happy that the joke was entirely on me. ... but my instincts and experience with SSL (so far) and with the debian package management system (so far), tell me otherwise (to date). the problem is: i've rather comprehensively fucked up relations with... i think it's now about... ooo, getting on for 30+ people in mozilla, who are getting so incensed that i'm quotes telling them what to do quotes that in true terry pratchett style it's going beyond annoying, gone out the other side and is bordering on becoming funny. i think saying "i know there are many of you who wish i was dead so that i'd stop typing" probably did it, this time. anyway, eno
Re: linux-image-2.6.39 not booting due to older package (not in list of dependencies!)
On Tue, Aug 2, 2011 at 2:05 PM, Luke Kenneth Casson Leighton wrote: > now, i've discussed this on the bugtracker and there clearly isn't - > and really shouldn't be - a listed debian dependency between > linux-image-2.6.39 kernel and a userspace library. however, there > clearly *is* a dependency because "It Don't Wurk (tm)". > > so the issue is: how the bloody hell should this clear dependency be > expressed in "Debian Dependency" terms, such that nobody else runs > smack into this same issue? ok i spoke to phil hands, and asked his advice: apparently there's something called "Breaks:" which would do the job. http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks this fulfils the requirements, namely that if you haven't got the package installed, it's irrelevant, but if you have, then the version must, clearly, be greater than N in order to work. thus, it would appear to be the case that the *older* libdevmapper library must have "Breaks: (< linux-image-2.6.39)" and this will force the installation of the newer libdevmapper *before* going ahead with the installation of linux-image-2.6.39. why must that be the case? very simple: if libdevmapper happens to be upgraded at the same time, and happens to get unpacked *after* initramfs-tools gets triggered [in the postinst?], then you have the nasty situation where the new (correct) library is correctly installed... but it was the *older* libdevmapper that was dropped into the initrd at the time of the 2.6.39 kernel upgrade. and that's known to be "Bad (tm)". the other nice thing about "Breaks:" is that it's the opposite of "Conflicts:" i.e. if you were to use "Conflicts:" it would have to go into the linux-image-2.6.39 package, and that would be just a bit... weird. @begin ot [plus, ben has completely ignored that he's been terribly insulting and believes that my responses pointing this out are themselves in fact insulting, and that all this ego insultingness including saying "you are a complete liar, your bugreport *must* be worthless" is something that justifies completely ignoring any further input, which is, itself insulting to say the least. thus, any further input from ben cannot be expected, and thus the way to fix the issue is to go from the "other end" i.e. fix the issue using "Breaks:". *sigh*. i really must actually try acting like the egofuckingmaniac that people believe i am, one of these days. perhaps if i pointed out more often that peoples' behaviour is very insulting rather than assuming that they know that, things would go a bit smoother. trouble is that i just don't notice the things that other people would, ordinarily, be completely outraged by, consequently get blamed rather a lot for being pathologically honest and blunt. oh well let's stop here, eh?] @end ot also it's not entirely clear (whereas "Breaks:" definitely is) that the use of "Conflicts:" would trigger a complete upgrade of libdevmapper before proceeding with the installation of the 2.6.39 kernel (or more to the point, proceeding with the initrd recreation). perhaps somebody with a bit more experience of how "Breaks:" and "Conflicts:" work would like to comment, thus ensuring that this issue is resolved in the best possible way for the benefit of the debian free software community? (*) l. (* i.e. ignoring that the report is coming from someone whom many debian developers feel is an "aggravating little shit who needs taking down a peg or two by deliberately seeing the absolute worst in whatever they write in order to *deliberately* create situations where afore-mentioned little shit can be proven wrong har har", because this particular aggravating little shit can in fact take care of his own system, whereas there are many debian users who, when presented with this same issue would find themselves completely lost) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedydwrzrn-ubuixmynupb1_qcsk5ffnyb85gi44u_xg...@mail.gmail.com
Re: Buggy/Stable java program (craftbukkit), possible ITP?
On Tue, 2011-07-12 at 14:29 -0700, Luke Cycon wrote: > Mhm. Mojang seems to be building a modding API which they say is going > to simply be a full release of the source code of the server. There is > a condition of use that whatever is made using the modding API must be > provided free of charge. (At least this is what I gather from crawling > over their site) Link is [1], a blog post from Markus "Notch" Persson, > owner of Mojang Spec, explaining this (Look near the end). > > I will try get into contact with someone at both Mojang and Bukkit and > see what could be arranged. > > To the contrib point: I still think that inclusion in contrib would be > very useful. I am open to counter arguments though. > > [1] http://notch.tumblr.com/post/6385865216/post-e3-information-dump Okay. The Vanilla Minecraft server is a lost cause, Markus says its closed source and they are not interested. He does say that Bukkit is a derivative of their intellectual property and that they have worked out a license deal. Seen as the LGPL notice is new, I would assume that is the license deal, but I will check with the Bukkit owner. Thanks, -- Luke Cycon signature.asc Description: This is a digitally signed message part
Re: Buggy/Stable java program (craftbukkit), possible ITP?
On Tue, 2011-07-12 at 13:41 +, The Fungi wrote: > On Tue, Jul 12, 2011 at 12:43:03AM -0700, Luke Cycon wrote: > [...] > > It is effectively an LGPL rewrite of the closed source Minecraft > > server. > [...] > > I gather that it's a partial reverse-engineer-and-patch layer for > Minecraft (so arguably a derivative work), and its legality is > currently under dispute according to the FAQ. All this would have to > be figured out before Debian could distribute it: > >"The Bukkit Team is currently in talks with the Minecraft >developers to sort out any licensing issues before we decide to >have an official release." > >http://wiki.bukkit.org/FAQ#When_will_Bukkit_be_released.3F > > Even once licensing is worked through, unless it becomes useful for > anything besides Minecraft or unless Mojang decides to release a > DFSG compatible version of Minecraft so that it too can be in > Debian, I suspect CraftBukkit would be relegated to the contrib > archive area (and thus not officially part of the Debian > distribution). Mhm. Mojang seems to be building a modding API which they say is going to simply be a full release of the source code of the server. There is a condition of use that whatever is made using the modding API must be provided free of charge. (At least this is what I gather from crawling over their site) Link is [1], a blog post from Markus "Notch" Persson, owner of Mojang Spec, explaining this (Look near the end). I will try get into contact with someone at both Mojang and Bukkit and see what could be arranged. To the contrib point: I still think that inclusion in contrib would be very useful. I am open to counter arguments though. [1] http://notch.tumblr.com/post/6385865216/post-e3-information-dump -- Luke Cycon signature.asc Description: This is a digitally signed message part
Buggy/Stable java program (craftbukkit), possible ITP?
Hey all, Available online is a game server called craftbukkit. It is effectively an LGPL rewrite of the closed source Minecraft server. It is widely used to run game servers, and I feel many users would benefit from a package containing the builds pre-setup to run correctly. (As it stands, server installation can be tricky for those not knowledgeable in Java.) This is all well and good, but the issue comes here: The software is currently under development and unreleased. That being said, its developer builds are still very stable. However, given such a large game (feature/game-play possibility wise), quite a few bugs do crop up. These bugs are inherently issues with the game/gameplay and are not easily fixed by anyone but the bukkit devs. My question boils down to this: Would it be outside the realm of possibility to package such a program and only accept bugs that have to do with its Debian specific packaging? The bugs are resolved rather fast by upstream, usually being fixed within a week. For this reason, my first thought would be to keep the package in unstable and keep a steady flow of updates. I haven't seen any packages like this one, but I can't say I led an extensive search either. If anyone knows of one, point me towards it so I can take a look! Looking forward to everyone's input, -- Luke Cycon 0x36A0D0AA Git Repo for craftbukkit: https://github.com/Bukkit/CraftBukkit Bukkit Homepage: http://bukkit.org/ signature.asc Description: This is a digitally signed message part
Re: Whether should grub2 write MBR automatic
On 06/22/2011 03:07 AM, YunQiang Su wrote: >> Did you? Try 'dpkg-reconfigure grub-pc' ;) >> > yes it works. BUT: > > When installing, user will usually install grub in MBR or they have > no choice to set it when install (install from LiveCD). If you install with a low debconf priority, or use preseeding, you can set it on install. IIRC, Ubuntu even asks if you want to write the bootloader at the default debconf priorities when using the alternative CD. On 06/22/2011 03:39 AM, YunQiang Su wrote: > Yes, if only for Linux distro, it can be done like this. Then if > there are Windows and Mac OS X? I'm not sure what you mean. > But I believe that debconf is not a good idea for grub. We can just > install some files and if need, call grub-install by > Debian-Installer or LiveCD-installer or users manually. > > It is both friendly to users and maintainers. Debian should work for the common case by default. I shouldn't install Debian on a commodity PC, then have it break on reboot because I forgot to install the bootloader and the installer didn't tell me about that People in special situations (dual booting, odd bootloader setup, etc) can set debconf to prompt on things with a lower priority to ensure the system is set up as desired. -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 signature.asc Description: OpenPGP digital signature
Re: Does anyone care about LSB on arm?
On Tue, May 31, 2011 at 5:22 PM, Wookey wrote: > In my experience anyone distributing binaries actually picks a small > set of distros and builds for those explicitly, rather than relying > on the LSB. Does that mean that it's not actually useful in the real > world? I guess in a sense this posting is to the wrong lists; we're > all free software people here who have little use for the LSB. Where > do the proprietary software distributors hang out :-) the proprietary software distributors hang out around USA lawyer offices, where they get advice on how to perform tivoisation without anybody noticing. they then ship TVs and even 3G modems with embedded linux kernels and custom OSes... and nobody notices. my take on this is that ARM is still just emerging from the "uselessness" of sub-600mhz ARM9s and ARM11s as far as general-purpose computing is concerned [laptop / desktop etc. *not* true embedded purposes obviously: don't get upset, ARM employees, because "mr LKCL said your processors were quotes useless quotes" - read it again: it's a *conditional* description]. also, the sheer diversity of SoCs plays directly, psychologically, against anyone "joining forces" on things like LSB. thus the majority of proprietary software distributors up until recently have been doing custom-built from scratch software stacks [using e.g. buildroot, openembedded] and thus LSB was and still is completely useless to them. even android is custom-built, and everything (except the highly-optimised apps - for ARM - which are becoming more common) is a java app. that having been said, 500mhz+ Dual-Core Cortex A9s already out which knock the stuffing out of 1.6ghz Intel Atoms (yes, saw the youtube video) mean that could just be about to change, completely. sooo... although the situation *right now* is that nobody in the commercial world is the slightest bit interested in LSB because they all do "custom builds" of complete software stacks, it could be said that *if* the free software community just dropped ready-to-go LSB standards in front of their noses, they'd quite likely use it. you have to remember that the majority of these companies could not put two lines of code together to save their lives. they literally have to be spoon-fed (in some cases even to the point of being told where to put the screws, let alone the software). they are usually spoon-fed by the CPU manufacturer [and in the case of MStar Semi, they won't even let *you* violate the GPL, they do it entirely for you]. so in that regard, i think it's more a case of "if the free software community provides LSB across ARM, it'll get used". so in _that_ regard, the question becomes: "are the efforts of the free software community better off being spent elsewhere"? and "what benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for ARM"? forget the proprietary junkies, they'll suck anything from us that moves and not give a dime in return. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimigcu991spdornpbh0zbnut+n...@mail.gmail.com
Bug#597985: ITP: pithos -- Pandora radio on the GNOME Desktop
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: pithos Version : 0.3.1 Upstream Author : Kevin Mehall * URL : http://kevinmehall.net/p/pithos/ * License : GPL-3 Programming Lang: Python Description : Pandora radio on the GNOME Desktop Pithos is a cross-platform desktop client for the personalized web radio Pandora, supporting all important features the official Flash™ client has. Pithos was based on pianobar, a console client for Pandora. In addition to sporting a GTK+ GUI, Pithos has feature-parity with pianobar. You need an account in order to use this player, so please consider create one for free before using pianobar at http://pandora.com. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100924222305.7360.36307.report...@localhost6.localdomain6
Re: Distributed Debian Distribution Development
On Thu, Sep 2, 2010 at 1:44 PM, Oscar Morante wrote: > Have you seen this project [1]? It looks like they have been already > thinking about the git+bittorrent idea. > > [1] http://code.google.com/p/gittorrent/ yes. it's effectively shelved. the name "gittorrent" was abandoned and the name "mirrorsync" selected, because the people working on it decided that bittorrent was an inappropriate protocol to use. i got them some slashdot coverage. but, ultimately, i disagreed with them that bittorrent isn't an appropriate protocol, so that's why i did the thingy and proved that it's an effective transfer / distribution mechanism. thingy. haven't even picked a name for it! :) suggestions welcome. i want to see how far i can get away with leaving the bittorrent protocol _entirely_ unchanged, by virtue of doing everything through this "vfs layer" jobbie. only if it becomes absolutely absolutely necessary, _then_ start making changes. good reasons to make changes: a) the 256k chunk size becomes blindingly obviously completely unacceptable. for example: cameron dale did a study of the .deb archives and found that a very large percentage are under 32k in size. this was the primary reason why he abandoned the bittorrent protocol (baby? bathwater?? *sigh*...) even after modifying it to be able to negotiate chunk sizes and he designed apt-p2p instead. b) ISPs start doing packet-filtering (fuckers) so it becomes necessary to change headers, port numbers, permanently enable encryption at a fundamental level such that deep packet inspection becomes impossible, e.g. move to SSL and so on. c) digital signing of individual commits becomes necessary, and... somehow (i don't know how yet) it *hand-waving* becomes necessary to integrate the GPG signature verification on git "packs" at the bittorrent-protocol-level. haven't got to that bit, yet - the project's only been going for 4 days! sam vilain solved this by simply creating refs with the signers' 32-bit GPG fingerprint, but he didn't get as far as actually _checking_ it :) l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikkyhzu_ws7ke3f-ntppdtxy9z6-pgn0pf7m...@mail.gmail.com
Re: Distributed Debian Distribution Development
On Wed, Sep 1, 2010 at 6:47 PM, Yaroslav Halchenko wrote: > Just - Wow... thanks! > > Hopefully digesting of this tasty post would not cause too much of farting ;-) :) > seems might be worth adding (if I am not missing the point), then the > concept of "derivatives" would then converge finally to a more > digestible, more manageable, and thus more robust mechanism of > branches... ? ahh, you're still using "git": i'll be doing nothing more fancy than creating a "git-remote-helper" which will add a protocol gitp2p:// or gpp:// or something like that. so you'll still need to understand the concept of branches and branching: it's just that you'd be able to grab them from peers rather than being reliant on a central server. imagine a situation where you meet a fellow debian developer(s) and you both(all) happen to be on holiday or just... somewhere where connectivity is patchy. i envisage a situation where both (or all) publish their own trackers, and they can simply share whatever bits of git repositories they (individually) happened to be "most interested in, personally", with everyone else. for example, one person happens to have an OCD-fueled interest in keeping up-to-date with every single mailing list, whilst another happens to be interested in some obscure piece of software. everybody collaborates, does loads of packages, GPG signs them, commits them to each others' git repositories, they all say bye bye nice meeting you, get on planes or goats and the VERY first person who happens to have internet access does a "git push", wham, everyones' packages are uploaded/available to the rest of the world. including those people who shared them originally, but they have the git commit refs already _in_ their database, so when _they_ get online as well, they automatically become "seeds" as part of the wider git-bittorrent network for those packages. so... yeah. it's a little... radical, but actually nothing more than a mind-shift rather than any actual significant coding. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktintf4xjugend0slotu341=bfaxsdrcwo=1wq...@mail.gmail.com
Bug#592923: ITP: python-aiml -- an Artificial Intelligence Markup Language interpreter for Python
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: python-aiml Version : 0.8.5 Upstream Author : Cort Stratton * URL : http://pyaiml.sf.net/ * License : FreeBSD Programming Lang: Python Description : an Artificial Intelligence Markup Language interpreter for Python PyAIML is an interpreter for AIML, the Artificial Intelligence Markup Language, implemented as a 100% pure standard Python package. The package is fully compliant with the AIML 1.0.1 standard: no less, but also no more. PyAIML's focus is (and will remain) bare-bones AIML interpreting. That means no support for obscure communication protocols, no advanced non-standard features, and no user interface to speak of. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814014014.11359.63355.report...@stone.home
Bug#592689: ITP: turtleart -- a LOGO-like tool for teaching programming
Package: wnpp Severity: wishlist Owner: Matthew Gallagher * Package name: turtleart Version : 93+git20100803.9bee2c4 Upstream Author : Walter Bender * URL : http://wiki.sugarlabs.org/go/Activities/Turtle_Art * License : Expat Programming Lang: Python Description : a LOGO-like tool for teaching programming Turtle Art is an activity with a Logo-inspired graphical "turtle" that draws colorful art based on snap-together visual programming elements. Turtle Art is intended to be a stepping stone to the Logo programming language, but there are many restrictions compared to Logo. However, you can export your Turtle Art creations to Berkeley Logo. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100812031446.16279.84844.report...@stone.home
Bug#591831: ITP: stackapplet -- panel applet to track reputation on StackExchange sites
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: stackapplet Version : 1.2.0 Upstream Author : Nathan Osman * URL : http://stackoverflow.quickmediasolutions.com/stackapplet/ * License : MIT Programming Lang: Python Description : panel applet to track reputation on StackExchange sites StackApplet is a GNOME panel applet that monitors your activity on any StackExchange site. StackApplet will notify you when your reputation changes on any of the sites or when someone posts a comment to you. StackApplet supports tracking multiple sites and usernames -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100805184945.22894.67724.report...@stone.home
Bug#590123: ITP: sugar-surf-activity -- WebKit-based browsing activity for the Sugar graphical shell
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: sugar-surf-activity Version : 115 Upstream Author : Lucian Branescu Mihaila * URL : http://people.sugarlabs.org/lucian/ * License : GPL-3+ Programming Lang: Python Description : WebKit-based browsing activity for the Sugar graphical shell Sugar is a graphical user interface aimed at children. Originating as intregral part of the OLPC "XO" a.k.a. the $100 laptop, Sugar has since grown into a more widely usable low-ressource desktop environment for kids. This package contains the Surf activity, providing a simple web browser based on the WebKit engine. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100723203559.24314.32004.report...@stone.home
Re: upcoming issues with python-hulahop, python-xpcom, xulrunner-1.9.2
On Wed, Jul 14, 2010 at 8:52 AM, Mike Hommey wrote: > On Tue, Jul 13, 2010 at 06:07:27PM +0000, Luke Kenneth Casson Leighton wrote: >> hi folks, >> >> i don't know if you're aware of the ... issues shall we say ... >> surrounding xulrunner 1.9.2 but there's a few changes going on. >> python-xpcom is being *dropped* from xulrunner as a first class >> citizen and is being turned into a third-rate one. this isn't a >> problem right now because debian releases versions of firefox that use >> xulrunner-1.9.1. >> >> the rdepends for python-xpcom include python-hulahop and >> pyjamas-desktop, epiphany-gecko, sugar-web-activity and so on. >> removal of python-xpcom basically screws these projects. > > epiphany-gecko is already gone. > >> to make matters slightly worse, the mozilla team have dicked with the >> xpcom interface c-code as they focus all-out on speed-speed-speed to >> the absolute pathological exclusion of all else, in an attempt to >> catch up with webkit's increasing mindshare. this decision is >> affecting all the language bindings (such as java-xpcom, python-xpcom >> and so on). >> >> so, right now, the situation is as follows: >> >> * if you upgrade firefox to a version which uses xulrunner-1.9.2, >> python-xpcom and its rdepends go out the window. >> >> * even if you happen to include the third party module >> http://hg.mozilla.org/pyxpcom as it is now known, xulrunner's XPCOM >> code has been been brain-damaged to the extent that several key >> strategic things such as python bindings to XMLHttpRequest will no >> longer work. todd whiteman has very kindly agreed to look at this, >> and to keep up with the brain-damage. > > For people interested in more intelligible information than the above > rant, ( it's a good one, innit? :) > some xpcom exposed interfaces in xulrunner have been "tweaked" > such that they will only work when called from javascript. Such > interfaces thus can't work from other xpcom bindings. yup. appreciate the clarification, mike. basically, an interpretation of the decision from the mozilla foundation is that all languages but javascript can get lost. i do not understand why, after years of support thanks to xpcom, _just_ when there's a project which actually _uses_ alternative language bindings 100% and i meaaan 100%, the mozilla foundation slams the door in its face and in the face of every other project using xpcom. it's not like there's a chance of any non-mozilla-foundation-funded project having the money to maintain a parallel version of xulrunner with a non-broken version of xpcom or anything. >> basically i wanted to appraise people of the situation, because, with >> xulrunner-1.9 being in debian/testing since pyjamas-desktop was added, >> any attempt to follow the mozilla foundation's headless-chicken >> meltdown moments means goodbye epiphany-gecko, sugar-web-activity and >> pyjamas-desktop. and... that would be bad :) > > I guess you mean xulrunner-1.9.1. yes. again, thank you for clarifying. > xulrunner-1.9.2 is still in > experimental and will stay there until squeeze is released. ok. thank god. so unless the mozilla foundation see the light, basically all projects that use python-xpcom must stick with xulrunner-1.9.1. that means that all linux distributions must maintain two parallel versions of xulrunner, or that they must "bundle" a version of xulrunner specifically dedicated to firefox _in_ firefox (just like the stand-alone releases made by the mozilla foundation itself). or, all linux distributions must tell python-xpcom-dependent projects to go to hell in a handbasket. those are some the options, and i'm interested to know a) if anyone has any alternative ideas b) which way the debian project is going to jump. i _could_ create and maintain and even submit a series of packages "xulrunner-1.9.1-to-deal-with-shortsighted-mozilla-foundation-decision", "python-xpcom-1.9.1-to-deal-with-shortsighted-mozilla-foundation-decision" and would be happy to submit patches to python-hulahop, sugar-web-activity and pyjamas-desktop packages, if that would help, but i am not entiiirely sure that would go down well :) l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiki3m5rwoxe3kdlipsgjn9hv50ua_brhfw54...@mail.gmail.com
upcoming issues with python-hulahop, python-xpcom, xulrunner-1.9.2
hi folks, i don't know if you're aware of the ... issues shall we say ... surrounding xulrunner 1.9.2 but there's a few changes going on. python-xpcom is being *dropped* from xulrunner as a first class citizen and is being turned into a third-rate one. this isn't a problem right now because debian releases versions of firefox that use xulrunner-1.9.1. the rdepends for python-xpcom include python-hulahop and pyjamas-desktop, epiphany-gecko, sugar-web-activity and so on. removal of python-xpcom basically screws these projects. to make matters slightly worse, the mozilla team have dicked with the xpcom interface c-code as they focus all-out on speed-speed-speed to the absolute pathological exclusion of all else, in an attempt to catch up with webkit's increasing mindshare. this decision is affecting all the language bindings (such as java-xpcom, python-xpcom and so on). so, right now, the situation is as follows: * if you upgrade firefox to a version which uses xulrunner-1.9.2, python-xpcom and its rdepends go out the window. * even if you happen to include the third party module http://hg.mozilla.org/pyxpcom as it is now known, xulrunner's XPCOM code has been been brain-damaged to the extent that several key strategic things such as python bindings to XMLHttpRequest will no longer work. todd whiteman has very kindly agreed to look at this, and to keep up with the brain-damage. basically i wanted to appraise people of the situation, because, with xulrunner-1.9 being in debian/testing since pyjamas-desktop was added, any attempt to follow the mozilla foundation's headless-chicken meltdown moments means goodbye epiphany-gecko, sugar-web-activity and pyjamas-desktop. and... that would be bad :) yes, you guessed it: ubuntu have indeed been led by the mozilla foundation on this merry chase, and have indeed just happily ripped out all the python-xpcom rdepends in the hope that noone would notice. so... just a heads-up. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktime__exg2vv9bbgin5cyrbopavaf_zykwvq_...@mail.gmail.com
Bug#588106: ITP: sugar-physics-activity -- A physical world simulator and playground for Sugar
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: sugar-physics-activity Version : 4 Upstream Author : Alex Levenson and Brian Jordan * URL : http://wiki.sugarlabs.org/go/Activities/Physics * License : GPLv3+ Programming Lang: Python Description : A physical world simulator and playground for Sugar You can add squares, circles, triangles, or draw your own shapes in the Physics Activity, and see them come to life with forces (like gravity),friction, and inertia. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100704210652.6455.83939.report...@stone.home
Bug#588105: ITP: python-elements -- python-box2d wrapper
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: python-elements Version : 0.13+svn230 Upstream Author : The Elements Team, * URL : http://elements.linuxuser.at/ * License : GPLv3+ Programming Lang: Python Description : python-box2d wrapper and physics API An easy to use API for integrating 2D physics (with pybox2d) into own python ideas, that includes user interfaces & simulations, as well as teaching & learning tools. This package depends on the packaging of python-box2d, which is filed in Bug #524710. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100704210110.5007.52307.report...@stone.home
Bug#587777: ITP: sugar-terminal-activity -- Sugar Terminal activity
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: sugar-terminal-activity Version : 28 Upstream Author : Eduardo Silva * URL : http://wiki.laptop.org/go/Terminal_Activity * License : GPL-2+ Programming Lang: Python Description : Sugar Terminal activity Sugar is a graphical user interface aimed at children. Originating as intregral part of the OLPC "XO" a.k.a. the $100 laptop, Sugar has since grown into a more widely usable low-resource desktop environment for kids. This package contains the Terminal activity, providing a VT100- compatible terminal emulator for the Sugar environment. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100701151443.5780.67843.report...@opus.home
Bug#586828: ITP: chipw -- custom level editor for TileWorld / Chip's Challange
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: chipw Version : 2.0.4.2 Upstream Author : Christopher Elsby * URL : http://www.microstupidity.com/chipw/ * License : GPL-2 Programming Lang: C Description : custom level editor for TileWorld / Chip's Challange Tile World is an emulation of the game "Chip's Challenge". "Chip's Challenge" was originally written for the Atari Lynx by Chuck Sommerville, and was later ported to MS Windows by Microsoft. This package contains a level editor for Tile World, and supports all tiles used in the game. Levels created using this editor can be played in both Tile World and Chip's Challange. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100622210727.5737.67661.report...@stone.home
Re: pid file security
On Sat, Jun 5, 2010 at 2:26 AM, Russell Coker wrote: > On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton > wrote: >> apologies for butting-in without being able to continue the thread, >> but i've just seen this: >> http://advogato.org/person/etbe/diary/779.html >> which links to this: >> http://lists.debian.org/debian-devel/2010/05/msg00067.html > > http://etbe.coker.com.au/2010/06/04/securely-killing-processes/ > > You're quick. :) it was pure chance: i saw it in advogato recentlog, which flashes by in a blur. > http://sourceforge.net/projects/depinit/ > > The above URL is one place to download depinit. It's an init replacement that > uses configuration files to give the details of services to start. yes. it's worth explicitly mentioning that it's a parallel-capable replacement for sysv init, and a bit more besides. it doesn't use inittab, for example. in another project that he did, richard i think even wrote his own /bin/login replacement because he didn't like the ones that were on offer _either_ :) which he then fired off from depinit, via a signal that is i believe generated for extraneous key-presses such as ctrl-alt-delete or alt-left or alt-right; in this way, pressing alt-right fired up another login console. >> depinit solved the fork-bombing issue because richard lightman was >> concerned about attacks on his internet-facing system. richard added >> code which actively tracks child signals (depinit is highly unusual >> and innovative in that it catches ALL signals, and can therefore react >> _to_ any signal) and analyses the timing etc. and provides a means to >> trigger arbitrary "scripts" based on the signal type. > > How does it do that? Does it ptrace them? i don't honestly know. richard was the complete frigging introverted genius, here, not me :) > http://etbe.coker.com.au/2010/05/16/systemd-init/ > > How does [depinit] prevent processes escaping? reaally don't know. apologies. >> richard also solved the security PID problem ... by doing away with >> the need for the PID file. > > That doesn't do away with the need for arbitrary programs to kill other > arbitrary programs and not make a mistake about which program they are > killing. yes. correct. i believe that depinit can manage / knows about only the services which it initiates, and are under its immediate control, by capturing all (16?) signals of its immediate child processes. >> FOREGROUND=True or whatever it is) and so on. in this way, there >> simply _is_ no need for a PID file, period. the relevant state >> information is contained within depinit itself, and you can guarantee >> that depinit will catch the signal. > > systemd does all that. excellent. >> and looked for "unauthorised login" attempts. more than three of >> those occurring within a specified time, and iptables would be called >> to block that user's IP address. voila: no delays due to syslog >> polling: instant and real-time attacker blocking, all using simple > > Does a program that uses inotify to wait for log file changes on disk > experience any delay of note? ... no - you're right: it wouldn't. so that would be a solution but again, it would require an application that had that capability [to use notify] - times however many services you wanted to react to, in real-time. so, an sshd-monitoring application would need to be written (in c?) to wait for inotify; an apache2-monitoring application would... etc. etc. however if that functionality was built-in to systemd, just as it is already built-in to depinit, i.e. if the services which were fired off foreground-style by systemd could have their stdin, stdout and stderr redirected to applications/scripts, as specified by command-line options to systemd... > The systemd option of creating sockets before executing services that listen > to them seems to offer the potential of more significant boot performance > benefits than just starting things in parallel. that's got my eyebrows raised - how the heck does _that_ work? i'm both surprised and intrigued. ok, darn it - systemd seems to be a really bad name choice: google search comes up with "Systeme D", and also systemd on windows?? ok, let's read this: http://etbe.coker.com.au/2010/05/16/systemd-init/ okaaay, riight. so. ah ha. it makes things quicker... by avoiding starting the services _entirely_ :) ok, so systemd is a merging of the functionality of sysv init and also inetd. right. let me think. insights. ok. inetd. usually inetd (and presumably systemd) services have their stdin and stdout redirected to the TCP/UDP ports, and you pass a specific option to the service to tell it
