OT high-power radio broadcasting (was Re: red SATA cable corruption)
The Debian whippersnappers need to know their hacker history :) I've heard the stories about getting caught on or near a tower. Supposedly you can feel it before it scrambles your brains. I would not seek out the experience. On 09/12/2018 02:08 AM, Gene Heskett wrote: Yeah, I've some experience. And it goes back quite a ways timewise.
Re: 9p/plumber to replace D-Bus?
On 12/12/2014 10:46 PM, Joel Rees wrote: 2014/12/13 3:44 Miles Fidelman mfidel...@meetinghouse.net: So... in all of this thread, I have yet to see anybody actually talk about 9p or plumber - details, and more importantly, in comparison to D-Bus. People are concerned about impacts to their particular use cases, which I understand I mean, 9p has been in the Linux Kernal for years (as compared to, say, kdbus), and it is actually used in some interesting places (erlang-on-xen, libvirt-to-quemu communications) where both the functionality and performance are rather critical. Does anybody have any direct, technical experience here? It does not seem to be widely used, but the more I look, the more I find examples of people asking the same questions. I have been thinking about installing plan 9 on an old box here, will probably do so. Right now, that box is my wedge for learning how to manage an openbsd box. (Plan 9 has some really interesting stuff, but I wouldn't be able to do some of my necessary work on it.) So, I've been reading the plan 9 website. Near as I can tell, p9 and plumber are less a replacement for the fluff that is dbus than a replacement for the infrastructure dbus is built on. Yes, it's a core infrastructure replacement. My guess is that dbus on p9/plumber would be so obvious and dead simple that we'd go back to dbus on sockets/signals/mmap/so-forth, and say to ourselves, Oh. Why did we bother extnding the desktop manager paste buffer like that? (Of course, I'm already saying that anyway, so YMMV.) That was my impression when I first read about Plan 9. It's dead simple and has an obviousness factor, although my summary may not be accurate: 1) The virtual hierarchical filesystem is used for local and network-wide access of all devices, storage, networks, and hosts. 2) The network is the computer, with security domains enforced by distributed agents (factotum). Per-process namespaces combine with the distributed filesystem to enforce security at all levels. 3) Per-process local and global namespaces are enforced by the security model. (If you can't see the resource, you can't access it.) 4) IPC uses a simple text message protocol (plumber) over 9p, which also provides a simple RPC mechanism. Sockets and APIs are not used, but an enhanced (bidirectional) version of Unix pipes is provided. 5) A reinvention of the GUI showcases all these features. I have not looked closely but I don't see much chance of replacing both D-Bus *and* the GUI in the near term. It's probably just too ambitious. Even ignoring 5) for the moment, that is a lot, just to replace D-Bus. Is the entire Plan 9 model required for D-Bus replacement? If not, which pieces can be used, and should they be full or partial implementations? If you don't implement the whole network is the computer model, do you just open up the debate that runs through this thread, about multi-user/multi-seat Unix? Do you end up with the worst of both worlds? Is it all or nothing, a complete replacement of userspace? In that case, maybe it would better to start with a Debian Plan 9 port (but that seems like a non-starter for various reasons). Due to issues like this, I am nowhere near proposing a real project, but this is still at the idea stage. -- Joel Rees -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548de4b9.30...@ix.netcom.com
Re: 9p/plumber to replace D-Bus?
On 12/11/2014 02:02 AM, Lisi Reisz wrote: On Wednesday 10 December 2014 18:08:00 Martin Read wrote: On 10/12/14 13:26, Marty wrote: The industry and its plans for FOSS is strongly anti-choice: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.h tml It appears to me that you have missed a point which seems to be implied by Lisi's choice of selective quotes. It was certainly intended to be! On the one hand, you say I would even deign to give users a choice in the matter, and on the other you suggest making functionality that real people are using on real computers go away. Quite. Choice means everyone must have what I want; I think there's a group at Red Hat meeting that description. Choice for them means, they choose, you follow. Apple, the leading vendor (I think now having supplanted M$) leads the way, showing how it's all done on a foundation of FOSS, and the world takes notice. The systemd manifesto makes no mention of freedom or use choice. Philosophy and ideology just get in the way. What's left is politics, and marketing. not everyone must be able to choose. It was choice the brought an entire generation of users to Linux and started the distributions, often with great expenditure of personal time and effort. Some of us are still willing to advocate for choice as a core principle Infinite choice is in the end not possible. But let us at least try to be honest and avoid hypocrisy. It was supposed to be a joke, so let's also not try to twist the issues beyond recognition. There's really no good answer for anyone with contempt for user choice who makes a mock defense to press a point. So yes, please he honest. Lisi By all means, embark on your endeavour in creating alternatives to D-Bus. Just remember that to be a convincing alternative, it has to solve *at least* the same set of problems. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548990f7.8060...@ix.netcom.com
Re: 9p/plumber to replace D-Bus?
On 12/08/2014 09:12 AM, Lisi Reisz wrote: On Monday 08 December 2014 13:18:18 Marty wrote: I would even deign to give users a choice in the matter, [snip] Multi-seat PC and other anachronisms probably have to go away. Choice??? Lisi The industry and its plans for FOSS is strongly anti-choice: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html I'm looking for a solution to that, not make it worse. This biggest issues I see at this point are non-technical, some political, some based on ignorance of the history of the computer industry and all of the fundamental technical issues surrounding it. I consider debian-user to have a better than average grasp of technical issues, but the confusion surrounding the systemd debate shrouded the issues here too, as it did elsewhere. People who are happy with their computer environments and don't see the issues and trends as problematic in any way, have my respect, even envy at this moment. I feel the same way as I did when RMS announced GNU and remember trying to decide how or if this will ever affect me, while listening to the lively office debates it inspired. It saw it as something that might even work. This time, I don't see a solution, a way forward, and that worries me. It's like the GNU announcement in reverse. Protecting Debian modularity and the Debian ports is a big issue that probably should not be left to package maintainers and the Technical Committee. It's their job, in a sense, but recent events prove that can't do it alone, and they (we users, Debian) are competing against paid devs and industrial development. I wish I had the answer, and I wish even there was consensus that this problem ever exists. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54884a0b.2000...@ix.netcom.com
Re: 9p/plumber to replace D-Bus?
On 12/10/2014 01:08 PM, Martin Read wrote: On 10/12/14 13:26, Marty wrote: On 12/08/2014 09:12 AM, Lisi Reisz wrote: On Monday 08 December 2014 13:18:18 Marty wrote: I would even deign to give users a choice in the matter, [snip] Multi-seat PC and other anachronisms probably have to go away. Choice??? Lisi The industry and its plans for FOSS is strongly anti-choice: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html It appears to me that you have missed a point which seems to be implied by Lisi's choice of selective quotes. On the one hand, you say I would even deign to give users a choice in the matter, and on the other you suggest making functionality that real people are using on real computers go away. The difference might be this: I would make an effort at backwards compatibility. I would not endorse any policy of intentional incompatibility requiring forced upgrades and lock in. That's probably where my plan falls apart, but it's too late for the cattle prod version of my plan. I'll be back as a sock puppet for that. :) By all means, embark on your endeavour in creating alternatives to D-Bus. Just remember that to be a convincing alternative, it has to solve *at least* the same set of problems. This discussion highlights how people often don't agree on what the problems are. I'm still stuck at not knowing where to start, but I've still learned something. Namely, that although technically all the pieces seem to be there, doing things on this scale is fundamentally not a technical problem. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5488f912.2030...@ix.netcom.com
Re: How is typical home computer used today?
On 12/10/2014 10:16 PM, Marc Shapiro wrote: On 12/10/2014 02:42 PM, Joe wrote: Proof of Concept. A bit short of a prototype. There are two different concepts here, almost no home *workstation* will be used truly multi-seat i.e. with more than one person connected simultaneously to it. A home computer may have multiple users, but generally not simultaneously. A simultaneous-multi-user computer is by definition a server of some kind. My home contains one of those, but most peoples' won't. They are becoming more common, with cheap Windows versions aimed at home server use, with a particular emphasis on media playing and backup of workstations. The tiny and very cheap Raspberry Pi and other similar devices are being used as servers, but generally for very limited purposes, and certainly not as multiple-user workstations. I think this is a particular issue for DEs, that causes the complexity in Linux desktops. You are not only sharing the display, but all of the devices, raising a number of technical and security issues. When the desktop is remote, there are other issues, like sharing sound over the network. My hunch is that all of these issues are related and derived from the old timesharing model. I am concerned about what Eric Raymond calls mission creep and bloat ... likely to turn into a nasty hairball. Even if systemd succeeds, and we learn that the only solution for these is a giant sprawling monolithic system that only the developers understand, I still think we need a new approach. My problem is that I don't know how or if a more distributed and modular approach would solve this problem, so that is one of the biggest uncertainties. snip My wife, daughter and I each login to a separate vt. It makes no real difference who logs on to which vt, but usually we each log in to a particular vt. snip Space is the reason for a single computer. If I can get the family room remodeled then we might set up a second computer (I have a spare sitting around doing nothing) there, but that is still one less computer than user. That seems like a valid use case. I wonder if a suspended VM would serve the same purpose. Hopefully there are other, better ways to do this. Marc -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548917ed.2060...@ix.netcom.com
Re: How is typical home computer used today?
On 12/09/2014 04:55 AM, Lisi Reisz wrote: On Tuesday 09 December 2014 08:59:34 Curt wrote: On 2014-12-09, Bret Busby bret.bu...@gmail.com wrote: So, what up to date operating system is, now? You cut his link to plan9; maybe that's it. Which is going to be so up-to-date that it can't use anachronisms like multi-seat, which are widely and currently in use. In fact, the use of multi-seat is growing. Lisi Decentralized computing. Sun's the network is the computer was an early experiment with this idea, Plan 9 was another. Is it easy? Nobody said it would be easy. As for what is growing, cloud computing, so they can look at our data and keep us safe. The app store concept is growning, and the unified solution is coming to distro near you, with TC/DRM as added bonus. Don't forget that OS-X is built on FOSS, blazing the trail. Centralized computing, centralized development, helpless users, mo' money. Even Wall Street gets it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54872803.5090...@ix.netcom.com
9p/plumber to replace D-Bus?
I almost tagged this off-topic but it's directed toward ordinary Debian users (with developer backgrounds). I first raised this on modular-debian but I want to get some ideas from a wider audience. I'm starting to get familiar with Plan 9 and D-Bus, to compare how they try to solve the same set of problems. Plan 9 concepts attempt to solve Unix problems in a very different way than Opendesktop.org. For people wanting to return to the original Unix concepts, 9p/plumber (or an updated version) seems like a natural fit going forward, for basic IPC purposes. 9p is already in Linux, and probably could be ported to the other Debian ports. I realize I just have to convince millions of people to re-plumb their core OS in a short period of time, but recent history teaches us that it that this is entirely feasible! Thus emboldened, I would even deign to give users a choice in the matter, but realistically, this would probably be an experimental project. Could an IPC bridge/shim mechanism connect to a new IPC model while apps and DE's migrate from D-Bus, or support both optionally? I can see an updated version of Plumber might be needed, and things might be simplified by other aspects of the Plan 9 paradigm, like per-process namespaces and treating everything as a file. Multi-seat PC and other anachronisms probably have to go away. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5485a51a.7040...@ix.netcom.com
Re: 9p/plumber to replace D-Bus?
On 12/08/2014 10:43 AM, berenger.mo...@neutralite.org wrote: Le 08.12.2014 14:18, Marty a écrit : I almost tagged this off-topic but it's directed toward ordinary Debian users (with developer backgrounds). I first raised this on modular-debian but I want to get some ideas from a wider audience. I'm starting to get familiar with Plan 9 and D-Bus, to compare how they try to solve the same set of problems. Plan 9 concepts attempt to solve Unix problems in a very different way than Opendesktop.org. For people wanting to return to the original Unix concepts, 9p/plumber (or an updated version) seems like a natural fit going forward, for basic IPC purposes. 9p is already in Linux, and probably could be ported to the other Debian ports. I realize I just have to convince millions of people to re-plumb their core OS in a short period of time, but recent history teaches us that it that this is entirely feasible! Thus emboldened, I would even deign to give users a choice in the matter, but realistically, this would probably be an experimental project. You won't convince anyone if you do not build a PoC. Especially developers giving their time literally for free. Asking questions is a nice way to learn how you could do that PoC, anyway. Asking and trying. If this proves feasible, that's what I hope to do. I just want to know if anyone thinks it's a good idea, before I commit time and resources. My knowledge of all of the issues is sketchy at best. I don't know where to start yet. It's obviously not a very original idea and I've read of people doing it in the past, some as research projects, but details are sketchy and I don't want to end up reinventing any wheels. Could an IPC bridge/shim mechanism connect to a new IPC model while apps and DE's migrate from D-Bus, or support both optionally? I can see an updated version of Plumber might be needed, and things might be simplified by other aspects of the Plan 9 paradigm, like per-process namespaces and treating everything as a file. Multi-seat PC and other anachronisms probably have to go away. As Lisi asked, what about choice? How could you say that those are anachronisms, too? Perl guys are used to say this: there is more than one way to achieve it. This can be applied to so many things. PC as time-sharing system was the anachronism that caused Bell Labs to scrap Unix, if I understand the history correctly. That's why I think it's a broken model that not survive. For me the choice is the option not to be tied to that broken model forever. As for choice to keep it, that's why I proposed an IPC bridge mechanism (although that's purely speculative). About anachronism... you should read about what is the minitel*, and then, consider thinking about how most people uses their computers ;) I started out designing terminals back in the stone age of computers, so I would have hard time giving up ttys and serial ports. :) *: http://en.wikipedia.org/wiki/Minitel Which I assume gave us minicom, right? Long live Minitel! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5485e70e.7060...@ix.netcom.com
Re: How is typical home computer used today?
On 12/08/2014 04:53 PM, Richard Owlett wrote: Lars Noodén wrote: On 12/08/2014 08:14 PM, Richard Owlett wrote: Exactly what is meant by Multi-seat PC? I'm working on defining a heavily customized personal installation of Debian. One of the *STRONG* underlying assumptions is the the machine would only ever be used by a specific individual. One of the underlying motivations is personally understanding the the guts of Linux. Multi-seat is where one machine is physically used by multiple users concurrently. One display, keyboard and mouse per user are plugged in to a single box and configured (with various amounts of fiddling) in X. It is used to good effect in classrooms and libraries, especially as thin clients. IIRC Brazil has some very large deployments. Regards, /Lars That what I thought it probaly meant. Thank you. Unix and X were developed around time-sharing, and are showing their age. Here is a quote from a document I came across recently: What was wrong with Unix? Not only is UNIX dead, it’s starting to smell really bad. − Rob Pike circa 1991 Designed as an old fashion timesharing system, has trouble adapting to a world of networks and workstations. The advantages of timesharing were lost in the switch to workstations: Centralized management and administration, amortization of costs and resources. Many features badly retrofitted over the years (eg., graphics, networking.) Lots of hanging historical baggage. Loss of conceptual integrity. Unix is not simple anymore. http://docs.huihoo.com/plan9/Plan9.pdf -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548644f4.9000...@ix.netcom.com
Re: Why focus on systemd?
On 11/26/2014 10:02 AM, Didier 'OdyX' Raboud wrote: I'm saying that §9.11 was not designed for anything else than ensuring that the Debian archive would keep working with the default init system of the time, nothing more. Except for its actual purpose, ensuring a choice of Alternate init systems. Reading between its lines to try convincing readers that it was designed to preserve init system choices That's what alternate means. You can choose. and prevent the kind of problems posed by systemd systemd has raised all these problems. is dishonest, IMHO. Feel free to go ask the policy editors if you disagree. No need, the policy is clear. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5476871d.3060...@ix.netcom.com
Re: Why focus on systemd?
On 11/24/2014 02:14 AM, Didier 'OdyX' Raboud wrote: Le dimanche, 23 novembre 2014, 18.09:58 Marty a écrit : Did I miss something? Yes. Option 1: init policy stands *won by default* [1] Option 2: change init policy *LOST* Option 3: ask nicely to follow init policy *lost* Option 4: policy stands, no statement needed *WON* Option 5: null option, further discussion *won by default* [1] depending on bug status of package dependence on PID 1, so maybe this is the real issue Iff you're using the same option numbers as those on the ballot, that's a totally wrong reading of the GR results, IMHO. Option 4 won all pairwise duels against all other options, and as such, is the winning option. All other options besides 5 (FD) won their pairwise duels against FD. Saying that Option 1 (…) won by default is factually wrong. It's summary was not init policy stands either. OdyX This is only my interpretation as an armchair observer, also in the US called Monday morning quarterback. It was a policy vote. The only results that matter are their effect on Debian Policy, right? The rest is academic. The vote invoked a clause in the TC init decision to allow modifying or overturning the policy set by the TC init decision, in anticipation of confusion or disagreement over its effect. Option 1 only restates or clarifies the existing init policy, 9.11, which is designed to preserve init system choices and prevent the kind of problems posed by systemd: However, any package integrating with other init systems must also be backwards-compatible with sysvinit ... So that leaves only the PID 1 question (hence my footnote). Note, however, that there is no reasonable way to claim that any package that only works with systemd as PID 1 could be regarded as backwards compatible with sysvinit, so Option 1 was a non-controversial interpretation of Debian Policy (as I read the -vote discussion). The only (or main) issue was only that it should be put to a vote, or at least put to a vote in this way, hence Option 4 was included. Option 4 states that the policy is fine and no restatement about PID 1 is needed. It does not say Option 1 is the wrong interpretation of policy. Only Option 2 overturns policy, by negating Option 1. Option 4 indirectly negates Option 2 and does not say anything about any other options. Option 1 therefore wins by default, especially if the (apparent) consensus about init coupling being a bug is affirmed in practice. The project seems to be saying that the issue should be resolved case by case and not be subject to a blanket rule, which seems reasonable to me. The vote also explains why the GR was rejected the first time around. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54732c74.8090...@ix.netcom.com
Re: Why focus on systemd?
On 11/24/2014 04:16 PM, Andrei POPESCU wrote: On Lu, 24 nov 14, 08:02:44, Marty wrote: It was a policy vote. The only results that matter are their effect on Debian Policy, right? The rest is academic. The vote invoked a clause in the TC init decision to allow modifying or overturning the policy set by the TC init decision, in anticipation of confusion or disagreement over its effect. Option 1 only restates or clarifies the existing init policy, 9.11, which is designed to preserve init system choices and prevent the kind of problems posed by systemd: However, any package integrating with other init systems must also be backwards-compatible with sysvinit ... I think you're missing a perhaps crucial point: the Debian Policy has not been updated yet to account for systemd being default, it still assumes sysvinit as default. See #591791, fixed in Policy 3.9.4.0, uploaded on 18 Sep 2012. Kind regards, Andrei I read a good bit of it. he first thing I notice is that it didn't take 9 months to update the policy. Maybe I missed your point. It looks like a successful application of policy that reinforces my interpretation, this message in particular: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#124 Just to be sure I rechecked 9.11, and it doesn't mention default init, so why would it be changed? What system besides sysvinit could provide backwards compatibility to serve the purpose of 9.11? In the TC discussion of bug #727708 there is talk (on the pro-systemd side) of hoping to change the policy changing in the future, after Jessie, but it was clearly not the issue under debate. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5473e656.7020...@ix.netcom.com
Re: Why focus on systemd?
On 11/22/2014 06:43 AM, Scott Ferguson wrote: On 22/11/14 22:14, Renaud (Ron) OLGIATI wrote: On Sat, 22 Nov 2014 21:46:19 +1100 Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote: It lost. Developers are not being forced to do what they don't want. The winner was developers will work it out themselves i.e. Debian won. Another reading being The Developpers won, Debian lost... Only reads that way if you have trouble reading - or simple refuse to acknowledge the view of Debian. Did I miss something? Option 1: init policy stands *won by default* [1] Option 2: change init policy *LOST* Option 3: ask nicely to follow init policy *lost* Option 4: policy stands, no statement needed *WON* Option 5: null option, further discussion *won by default* [1] depending on bug status of package dependence on PID 1, so maybe this is the real issue The good new is there's an explanation for those that can't read:- http://blog.halon.org.uk/2014/11/barbie-the-debian-developer/?utm_source=rssutm_medium=rssutm_campaign=barbie-the-debian-developer Cheers, Ron. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54726946.7050...@ix.netcom.com
Re: Why focus on systemd?
On 11/23/2014 06:48 PM, Miles Fidelman wrote: Marty wrote: On 11/22/2014 06:43 AM, Scott Ferguson wrote: On 22/11/14 22:14, Renaud (Ron) OLGIATI wrote: On Sat, 22 Nov 2014 21:46:19 +1100 Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote: It lost. Developers are not being forced to do what they don't want. The winner was developers will work it out themselves i.e. Debian won. Another reading being The Developpers won, Debian lost... Only reads that way if you have trouble reading - or simple refuse to acknowledge the view of Debian. Did I miss something? Option 1: init policy stands *won by default* [1] Option 2: change init policy *LOST* Option 3: ask nicely to follow init policy *lost* Option 4: policy stands, no statement needed *WON* Option 5: null option, further discussion *won by default* [1] depending on bug status of package dependence on PID 1, so maybe this is the real issue Well... maybe a commitment on the part of the debootstrap maintainers to apply test the existing contributed patch that fixes but #668001, sometime real soon after Jessie is released would go a LONG way to putting a lot of these issues to rest. That way, it would be straightforward to preseed a sysvinit based install, and maybe everything will just work, or at least we'd have a basis for starting to work through the bugs associated with a clean sysvinit install that doesn't involve rolling your own version of a patched installer. Miles Fidelman Or just use a testing version of the installer, and then there's the Jessie-ignore wild card, which was agreed to be liberally applied because none nobody wants to play lawyer. In the end I guess the issue is put to rest if policy is allowed to stand through Jessie+1 freeze, and overturning takes two thirds majority if I understand correctly. As things stand multi-init support looks good and the best way for systemd opponents to be their own worst enemy is to buy into the notion that their side has lost. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54729987.7040...@ix.netcom.com
Re: The systemd MacGuffin
On 11/18/2014 10:15 AM, Keith Peter wrote: On 18/11/2014, Miles Fidelman mfidel...@meetinghouse.net wrote: Marty wrote: I started posting here when, after years of promoting Linux to friends and employers and finally seeing much progress, my company started phasing out Debian (systemd was not the only issue but more of a last straw). Might I ask: - what the other straws were, Problems thought to result from a trend away from a general-purpose orientation, I think. Sorry about the vagueness. I'd rather not discuss the details because I didn't have direct involvement, and I don't want to speak for the company. For all I know they might have been upstream issues. - what your company is migrating to? Didn't ask, probably don't want to know. :/ Regards, Miles Fidelman In addition, I'd be quite interested to know what it was about systemd that added to the decision to phase out Debian. I think that kind of information would be confidential, and I am not authorized to say, nor was I directly involved. Was it custom init scripts and the upgrade process, or some odd function that has been lost? cheers None of those kinds of things, which are only the fodder of internet debates, so at least I can answer in the negative. Businesses care only about risk and cost. They use their own experts and do their own evaluation, or outsource that expertise. Beyond that, I'll just let my company's decision speak for itself. My company is just one data point, though, and I brought it up only as an explanation of my own response to recent developments. It's not meant as a commentary on Debian, systemd or my employer. In the meantime I want to focus on keeping Debian modular in order to help with any resulting integration issues. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546d7e59.6020...@ix.netcom.com
The systemd MacGuffin
The systemd issue in Debian (not systemd itself) is like exploring a cave system which seems to go on forever. It has so many facets and subplots that it seems impossible to evaluate objectively. It's the perfect storm for Debian. It's hard to imagine a more polarizing issue. It's conceivable that the Unix paradigm is too limiting for the universal OS, and this is the chance to break through it, without breaking out. Maybe resisting the Borg really is futile in this case but we can send all the clones to deprogramming classes. We have all been programmed by the Borgs of Redmond and Cupertino, to varying degrees. I started posting here when, after years of promoting Linux to friends and employers and finally seeing much progress, my company started phasing out Debian (systemd was not the only issue but more of a last straw). If I take that as a bellwether if Debian's success or failure, however, I put it on a par with commercial distros, and that is not what Debian is all about. To keep volunteer interest it should be nimble and take risks. In the end, I think systemd is a MacGuffin, a distraction from deeper issues that are really driving the debate. It's also a time and energy sink, and a stressor for me and (assume) others. It represents debates that has been suppressed for years at both individual and social levels in the name of peace, harmony and conformity. Linux was never about conformity. It is the ultimate disruptive technology. I agree with systemd proponents who say there was no need for administrative action, the GR no-op. I also agree with opponents who say we need clear direction from leadership, something they cannot give when they themselves are paralyzed with disagreement. The systemd issue is a tale told by an idiot, a mirror to the collective mind of the FOSS community, both crazy and sane, funny and serious, all at the same time. If the proponent side wins the GR vote I'll probably report some sysvinit bugs out of self-interest. If the opponent side wins I'll probably report systemd bugs, for Debian's sake. I've never been able to decide which side is which in the Linux Civil War but if the analogy holds, I'm on the Union side. I'll take the debate with equal doses of stress and humor, and try to remember the stakes after FOSS has arrived on the world stage and become a player. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546b3ff7.2070...@ix.netcom.com
Re: init scripts [was: If Not Systemd, then What?]
On 11/17/2014 01:13 AM, Andrei POPESCU wrote: On Du, 16 nov 14, 13:22:54, Marty wrote: On 11/16/2014 11:50 AM, Miles Fidelman wrote: In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Each one a bug as per Debian policy (sysvinit support). Looks like we have our work cut out for us. Would you please be so kind to point out which bullet point contradicts which Policy section? Kind regards, Andrei Don't they all by definition? Did I miss something? I suspect the workaround in all cases is sysvinit-core, but the warning still applies to anyone who runs the default configuration. For the record, since you omitted my smiley, I don't assume these are not already well known, or that I am planning to file bug reports. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5469ea0c.3050...@ix.netcom.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/17/2014 01:54 PM, Ludovic Meyer wrote: On Sun, Nov 16, 2014 at 08:29:28PM -0500, Marty wrote: On 11/16/2014 03:32 PM, Ludovic Meyer wrote: On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote: snip My point is that in a modular design nothing should be so entrenched as to be irreplaceable. Absence of an alternate should not normally indicate impossibility of an alternate, but some discussions I've read about logind, udev and dbus are enough to raise serious concerns. The problem is that, without any action, the difference between nothing can be replaced and it can be replaced is purely theorical. The problem is very real, but there seems to be no agreement about solutions, which by itself is evidence of a problem. There is not even anyone keeping a list of the solution or even the problem. Even the basis are not done. If you truly want to iterate on a solution, you should start doing it and document it. There *are* people doing it, e.g. systemd-shim, uselessd, nosh and eudev, the refracta team, and others. There are so many projects, it's hard to know where to join in, but I'm willing to help if I can. Now you can discuss for years in theory, In fact, people have been discussing this problem for years. And how did it change anything ? It didn't. So what make you think that yet another year is gonna result in something ? Right now Jessie is seems to have acceptable sysvinit support. The main concerns seem to be about Stretch, but that's 3-4 years away, so I think there's time to work on solutions. I do not want to be too critical, but that's the exact problem that the troll in the Hobbit face, by discussing endless on how to cook the dwarfs, they get petrified. And maybe the time to test and get something wrong, as itcan hardly be slower than discussing. The whole agile methodology. Keep in mind this is a mostly volunteer project, with a lot of people working in their spare time. if this doesn't result in any practical outcome, you have just stresstested the mailling lists software. Until there's a rough consensus and a clear way forward, I don't think many people will commit to specific solutions. There are also unknowns like kdbus, to further complicate the matter. Talk is cheap, as Linus said. You seems to be in favor of design by comitee, but this doesn't seems to work for now. I think small teams are the way to go in FOSS. People who just say, write your own, it's all FOSS are missing the point, I think. Debian is not one guy working in his mom's basement. It's one of the world's largest software projects. When Debian is stumped, because its best developers and upstreams are caught in the entanglement hairball, and see no clear way out, the it's clear case of *Houston we have a problem.* That's a interesting point, because with all those brillant minds, a vast majority do not even seems to care about this entanglement hairball. Maybe it is time to admit you do not know the whole details and accept that if developpers do not care, then they are maybe right in doing so ? Especially since you have been unable to give any technical reasons to why you do not want it, and how you would proceed. For you, I would start by explaining the Unix Philosophy and how it is a critical aspect of Debian's design: http://en.wikipedia.org/wiki/Unix_philosophy That's not a technical reason. It's a philosophy, and not even the dominant one in the software industry, but it is about technology and engineering, and part of the culture and design of Debian. I recognize that it also clashes with the universal operating system moniker, because the whole world is not Unix, so I see a place in Debian for monolithic OSs like systemd and Android clones, but I would have been more conservative about introducing it. Then I would proceed to explain how various aspects of systemd conflict with this, causing said hairball. Finally, I would explain (to the best of my ability) how the entanglement issue precludes a quick resolution, and the delay does not indicate lack of interest. And how would that be a technical reason ? If you disagree with the philosophy, that's not a technical problem. That's just a opinion. Show a real technical issue, not here is the design decided 20 years ago and that was ignored by several others components. Design philosophies have major technical implications. If Debian had started with Windows 3.1, I don't think the project would be where it is today. Loose package coupling works well with volunteer projects. For systemd to work in Debian it has to work within the existing modular framework, and I think it can be done, with difficulty. heck, even in 1989, people wrote the unix hater handbook to explain how the philosophy is wrong. For example, the example of cat not being following this design anymore. No one throw a fuse over it, despites being here, documented and visible by all since more than 20 years. You forgot to include
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/16/2014 05:26 AM, Laurent Bigonville wrote: Le Sat, 15 Nov 2014 20:21:49 -0500, Marty mar...@ix.netcom.com a écrit : On 11/15/2014 06:49 AM, Andrei POPESCU wrote: [...] At least some of people rejecting systemd demand that it be removed completely, including libsystemd. How is it pro-choice to forbid me from being able to use a software at its full potential? For me it's more about being unable to remove it completely, because of vendor lock-in. There's no technical reason that I know of that anything in userspace cannot modular, and replaceable, so when something cannot be replaced then an alternative must be provided, or else my default assumption is that vendor lock-in is in effect. Well, yes there are technical reasons why you cannot remove a library package when you have symbols provided by this library used in an executable. You can still recompile the package and remove some configure flag if you want to remove this dependency. OTHO there is no technical reasons that I can see, to completely remove libsystemd package. You have tenth of other libraries on your system that, like libsystemd, turn them self into a noop if some some functionality or daemon are not enable. I'm thinking here for example about libselinux and libaudit (both also written by Red Had and the NSA, OMG!!!11), and yet I fail to see any outcry here... So as long as you cannot _prove_ that having libsystemd installed on your machine is causing any issues, I'll personally mentally classify your request as I don't want to see any packages containing the systemd string on my machine and redirect these to /dev/null. Except that proponents seem more prone to avoiding the hairball issue by just covering their eyes. ;) My point is that in a modular design nothing should be so entrenched as to be irreplaceable. Absence of an alternate should not normally indicate impossibility of an alternate, but some discussions I've read about logind, udev and dbus are enough to raise serious concerns. People who just say, write your own, it's all FOSS are missing the point, I think. Debian is not one guy working in his mom's basement. It's one of the world's largest software projects. When Debian is stumped, because its best developers and upstreams are caught in the entanglement hairball, and see no clear way out, the it's clear case of *Houston we have a problem.* -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468e754.4020...@ix.netcom.com
Re: init scripts [was: If Not Systemd, then What?]
On 11/16/2014 11:50 AM, Miles Fidelman wrote: In the later case, one just has to read: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ to get very, very scared Each one a bug as per Debian policy (sysvinit support). Looks like we have our work cut out for us. Among the implications of this, the old standby of installing software from upstream (bypassing packaging), has just gotten a lot riskier. We have been exhorted to report bugs instead of complain on the mailing lists, nice of Freedesktop people to list them for us. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468eb7e.3050...@ix.netcom.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/16/2014 03:32 PM, Ludovic Meyer wrote: On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote: snip My point is that in a modular design nothing should be so entrenched as to be irreplaceable. Absence of an alternate should not normally indicate impossibility of an alternate, but some discussions I've read about logind, udev and dbus are enough to raise serious concerns. The problem is that, without any action, the difference between nothing can be replaced and it can be replaced is purely theorical. The problem is very real, but there seems to be no agreement about solutions, which by itself is evidence of a problem. Now you can discuss for years in theory, In fact, people have been discussing this problem for years. if this doesn't result in any practical outcome, you have just stresstested the mailling lists software. Until there's a rough consensus and a clear way forward, I don't think many people will commit to specific solutions. There are also unknowns like kdbus, to further complicate the matter. People who just say, write your own, it's all FOSS are missing the point, I think. Debian is not one guy working in his mom's basement. It's one of the world's largest software projects. When Debian is stumped, because its best developers and upstreams are caught in the entanglement hairball, and see no clear way out, the it's clear case of *Houston we have a problem.* That's a interesting point, because with all those brillant minds, a vast majority do not even seems to care about this entanglement hairball. Maybe it is time to admit you do not know the whole details and accept that if developpers do not care, then they are maybe right in doing so ? Especially since you have been unable to give any technical reasons to why you do not want it, and how you would proceed. For you, I would start by explaining the Unix Philosophy and how it is a critical aspect of Debian's design: http://en.wikipedia.org/wiki/Unix_philosophy Then I would proceed to explain how various aspects of systemd conflict with this, causing said hairball. Finally, I would explain (to the best of my ability) how the entanglement issue precludes a quick resolution, and the delay does not indicate lack of interest. In fact, a quick google check would even give you the required knowledge of why it is better to link : http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html You can compare the code with link to systemd library vs cut and paste in every source code. As a exercise, you can surely add use dlopen() and see which one is simpler and easier to maintain in the long term. Then it will be your turn to explain why it is better to cut and paste or link statically the library, or why it is better to have to patch every upstream to use dlopen(). Not sure how we went from entanglement issues to PID tracking, but granting your point, it still doesn't explain how we arrive at kdb, console and qcodes in PID 1. :) And once you will have been able to justify that on a technical level, maybe people will start to listen to you. For the record, see also the discussion on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980 You did not make much of a case for a complex PID 1 process, and on that question I defer to a kernel dev who takea a rather dim view of it: http://lwn.net/Articles/618024/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54694f78.6090...@ix.netcom.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/15/2014 06:49 AM, Andrei POPESCU wrote: On Vi, 14 nov 14, 08:04:00, Marty wrote: On 11/14/2014 05:26 AM, Andrei POPESCU wrote: On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: snip Jumping in here as myself, not Joel's tag-team member. :) Debian as an entity doesn't really do much. There are only one or several volunteers who start doing things. Setting up a separate port for systemd would have been a major waste of resources (both human and hardware) with no real gain. By the same token systemd is a major waste with no real gain. It duplicates equivalent modular alternatives, and also requires unnecessary effort to repair damage from excessive coupling. I challenge you to come up with a configuration that duplicates systemd's features with a combination of other software. http://0pointer.de/blog/projects/why.html You are completely dismissing the work of Debian Developers who *did* have a very good look at the options and decided switching to systemd is doable and would be a good thing from a *technical* point of view. Non-responsive to his argument. If the work was biased and over-optimistic then it doesn't matter how much they looked at it. This argument cuts both ways :) However, you and several others are rejecting systemd on ideological grounds. There's not much that can be done about that, short or re-implementing systemd according to your vision. Many others reject choice and the anti-choice stance is the ideological position at issue here. It is in direct conflict with Debian policy. The systemd upstream are the ones with vision, ideology, rejecting opponents as haters in an overt campaign to establish a Linux monopoly. They have a financial interest in *psychological projection* of this kind. I still cannot see what Debian stands to gain by jumping on their marketing bandwagon. At least some of people rejecting systemd demand that it be removed completely, including libsystemd. How is it pro-choice to forbid me from being able to use a software at its full potential? For me it's more about being unable to remove it completely, because of vendor lock-in. There's no technical reason that I know of that anything in userspace cannot modular, and replaceable, so when something cannot be replaced then an alternative must be provided, or else my default assumption is that vendor lock-in is in effect. I hope you do understand why neither the systemd developers, maintainers or users have any interest whatsoever in doing that. But upstreams have other interests, like establishment of a Linux monopoly via tying and customer lock-in. Why should there not be a rational effort to counter that? In my opinion the best defence against a monopoly[1] of any kind is to develop competitive alternatives. That's true on a level playing field, but here is just one player with control of the user-space software stack, fully leveraging it by dependency tying. It's like a manufacturing business that creates a monopoly by vertically integrating, in a way that no competitor can. [1] which I don't believe applies, but will ignore for the moment. They seem determined to make it apply in the future, so that's what drives the original concern (for me). It may apply in a way you are not expecting. After all, systemd already works fine for them. Windows already works fine for most people, and it is consistent with the anti-choice philosophy, so why bother with Linux at all? Doesn't work fine for me. At $dayjob I'm forced to use it and I can tell you my private laptop with a Dual Core 1,8 GHz and 2 GB RAM runs circles around a Core i5 with Windows 7. But this is off-topic for d-u. It might be somewhat on-topic after all, because I was thinking more about Windows 10, which is Red Hat's likely target and competitor. Debian and the other free software distros are just Wall Street cannon fodder. Kind regards, Andrei -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5467fc2d.7010...@ix.netcom.com
Re: Installing an Alternative Init?
On 11/15/2014 07:45 PM, Ludovic Meyer wrote: On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote: On 11/11/2014 02:16 PM, Brian wrote: On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote: On 11/11/2014 12:07 PM, Laurent Bigonville wrote: There are no functional differences between an installation with sysvinit-core out of the box or an install where sysvinit-core is installed later, this is a fact. Allowing the user to choose this at install time from the interface is a nice to have feature (wishlist bug) not a RC bug like you were claiming earlier. There is a potential practical consequence of not advertising an init alternative during setup. It makes users less likely to be aware of it, or even aware that the init system has changed. New users do not need to be be aware of all the background to the choosing of a default init. No advertisement is needed. By definition, they do not care. They want Debian. Please let them have it. They will not care by definition only if they are not aware of the change, and most won't be aware unless they are informed during the installation. They won't know they lost the choice they didn't know they had. Capisce? What choice have they lost? They lost an *informed* choice. I think the installation program should not take sides but just inform the user. A choice that the user is not aware of is the same as no choice, and is potentially coercive and disrespectful. It makes Debian seem partial to Red Hat's business plan to take over the Linux ecosystem. If you care so much about Redhat code, maybe you should document yourself, and see there pay coders for glibc, gcc, the kernel ( a ton of them, according to lwn and linux fundations reports ), on coreutils, gnome, kde, php, python, openssh, etc, etc. Whatever it was, it didn't exist as you imply in Wheezy. It wasn't an issue in Wheezy because the default init option had not changed from the previous release, and any release before that. They won't know, that is, until it bites them somewhere down the line. Then they won't know where to look or who to blame, and will blame Debian. What bites them? Individually, probably something that requires sysvinit or one many core services that got replaced. Collectively, getting trapped by vendor lock-in. You keep using those words, but you do not seems to use them correctly. If the same system is present on more than one distributio, that's not vendor lock-in since you can switch distribution and then reuse the same system. I meant that one vendor seeks to control the Linux ecosystem. Whether that plan is viable or even sane, is another issue, but I am not eager to see if their plan will succeed or be a guinea pin in the experiment. (I would like to see systemd succeed in Debian, however, *without* sacrificing modularity or user choice. That would be like embrace and extend in reverse, and could serve to protect downstreams.) Being tied to one package format ( and so on the ecosystem around ) would be true lock-in. And no one complained that much since Debian existed, despites the .deb having a few shortcomings at start, shortcomings that were fixed later such as having checksum of installed software, a feature rpm had at a time the dpkg didn't ( around 2002, so that's really a old stuff ). In both cases it could be the result of users being steered to the default init by the installation program, leaving alternatives to rot. Alternatives will rot if no one use them, so either you recognize than no one is interested to use them and it will indeed rot, or that the few interested to use them are unable to fill bug reports and help the alternatives survives. Given that a reading of the archives here show less than 50 people by a large margin complaining on this list, I would indeed see that as a minority. ( as I hope there is more than 100 000 to 1 million Debian users, since Ubuntu speak of 20 millions, Fedora speaking around 2 or 3 millions. But that doesn't matter, since 100 000 or 1 million, there would still be far less than 1% of the user base ). I don't think Debian (or FOSS, for that matter) was ever about a winner-take-all approach to software choice. That seems to have originated in the commercial distributions, which have a financial interest in a) controlling users and b) controlling costs. I don't think that philosophy was ever part of Debian in the past. I had thought that all it takes is one interested maintainer to keep a package alive in Debian. You might also be simplifying the problem. Software entanglement is a complex technical problem. There's a reason it's regarded as lock-in, because it's a technical cage that can be hard to break out of. It herds users in one direction, so the popularity issue is not only irrelevant, but misleading. I don't think there is a direct relationship between the number of users of alternate software, and the importance of maintaining it. I would say it's more of an opposite
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/14/2014 05:26 AM, Andrei POPESCU wrote: On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: snip Jumping in here as myself, not Joel's tag-team member. :) Debian as an entity doesn't really do much. There are only one or several volunteers who start doing things. Setting up a separate port for systemd would have been a major waste of resources (both human and hardware) with no real gain. By the same token systemd is a major waste with no real gain. It duplicates equivalent modular alternatives, and also requires unnecessary effort to repair damage from excessive coupling. The systemd folks claimed it wouldn't be necessary. If we had looked at the situation with an unbiased eye, we would have known they were being overly optimistic. We still turn a blind eye to the problems, claiming that the only problems are a bunch of recalcitrant noisemakers like yours-truly. You are completely dismissing the work of Debian Developers who *did* have a very good look at the options and decided switching to systemd is doable and would be a good thing from a *technical* point of view. Non-responsive to his argument. If the work was biased and over-optimistic then it doesn't matter how much they looked at it. And yes, that included the costs for the migration. Those are largely TBD ast this time. As far as I can tell by watching debian-user, debian-devel and pkg-systemd-maintainers the integration of systemd is mostly working fine and remaining issues (not all in systemd itself) will be dealt with before the release. The freeze could help with that, since the number of variables is reduced greatly. From the same lists, I can't tell whether non-systemd use will result in second-class citizenship and effective vendor lock-in for most users. However, you and several others are rejecting systemd on ideological grounds. There's not much that can be done about that, short or re-implementing systemd according to your vision. Many others reject choice and the anti-choice stance is the ideological position at issue here. It is in direct conflict with Debian policy. The systemd upstream are the ones with vision, ideology, rejecting opponents as haters in an overt campaign to establish a Linux monopoly. They have a financial interest in *psychological projection* of this kind. I still cannot see what Debian stands to gain by jumping on their marketing bandwagon. I hope you do understand why neither the systemd developers, maintainers or users have any interest whatsoever in doing that. But upstreams have other interests, like establishment of a Linux monopoly via tying and customer lock-in. Why should there not be a rational effort to counter that? After all, systemd already works fine for them. Windows already works fine for most people, and it is consistent with the anti-choice philosophy, so why bother with Linux at all? Kind regards, Andrei -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5465fdc0.7030...@ix.netcom.com
Re: Possible comprommission, what to do ?
On 11/13/2014 03:57 AM, Erwan David wrote: I just got a call form police, that they have arrested a pirate who tried to connect to one of my (debian) servers. They tell me he is gifted, but since the policewoman I had one phone mixes server, web site and email address, it may not be completely accurate. However, I'd prefer be sure my server was not compromised, and at the lower possibe cost (in time and work). Is there a way to check the packages/installed files from outside sources (I may boot a fresh live system in order to have clean utilities), or even provoke a reinstall with a new download of the whole system ? Thank you. It's clearly not the most efficient way, but I use debsums against my local repos, like this one line script: # cat check-debsums debsums -ca --generate=all --deb-path=/mnt/$1/install/deblinks The deblinks directory just contains links to all debs in the repo: # cat make-deblinks DEBIAN_DEST=$1 #rm -rf $DEBIAN_DEST/deblinks.old rm -rf $DEBIAN_DEST/deblinks #mv $DEBIAN_DEST/deblinks $DEBIAN_DEST/deblinks.old mkdir $DEBIAN_DEST/deblinks cd $DEBIAN_DEST/deblinks find $DEBIAN_DEST/debian* -regex .*\\.deb$ | while read filepath do #echo $filepath file=`echo $filepath | sed 's/.*\///'` #echo $file' would be linked to '$filepath ln $filepath $file done -- As I said, not efficient, but who cares? It's easy and I don't have anything public facing, and it only takes a few minutes to check each upgrade. Obviously the safest thing is reinstall from the package list. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5464ab99.3040...@ix.netcom.com
Re: Joey Hess is out?
On 11/12/2014 07:48 PM, Gary Roach wrote: On 11/08/2014 04:19 AM, Keith Peter wrote: Hello Bret and All Mr Hess was writing to the 1000+ Debian developers so the subject line *may* have made instant sense to them, but I take the wider point. We had better explain the 'so long and thanks for all the fish' quote as well (looking at your sig) for the benefit of others. In one of the volumes of the *The Hitchhiker's Guide to the Galaxy*, a very funny mock science fiction story, the dolphins all suddenly disappear. They have in fact left Earth because they know that the planet is about to be destroyed to make way for a hyperspace route. They send the message 'so long and thanks for all the fish' to the humans by swimming in a certain configuration (I recall). Mr Hess has made some definite choices about work/life balance [1] and I'm sure he will find an outlet for his considerable talents. I think that Mr Hess's approach to things is to focus on the *rules that define the process* (i.e. the Debian constitution) rather than any specific contingent features of the way the process is unfolding at present (the init/integration thing). If there are any long time users here, I too would like to know more about the Constitution and the history. I did find a chapter from someone's thesis [2] which seems to describe the transition from a small community of developers working on 'rough consensus' to a larger and more formal organisation. It is a bit academic but seems to ring true in the present circumstances. [1] http://joey.hess.usesthis.com/ [2] http://www.law.nyu.edu/sites/default/files/ECM_PRO_067658.pdf Cheers On 8 November 2014 07:31, Bret Busby bret.bu...@gmail.com wrote: I posted this on a very abreviated thread a couple of days ago but feel that it probably belongs hear. -- After reading the foofaraw over the word out, I took the time to read Joey Hess' abdication message and then the Debian Constitution that seems to be the center of his complaints. I am sorely confused. I have been using Debian for over 15 years and have seen Hess' name associated with an unbelievable number of projects. His worth to the Debian development effort can not be overstated. But after reading the Debian Constitution, I wonder what is really wrong. I find the document somewhat convoluted but doubt that I could do any better. Without a document that carefully outlines the rights and responsibilities of the participants in an endeavor of this size, the whole development effort would sink into chaos. Could it be a simple case of burnout? Maybe a discussion of why such a valuable member of the community would throw in the towel would be more productive. -- I have had experience with various large endevors (more that 6-8 people) in the past. Believe me, you don't want to do it without some pretty iron-clad rules to go by. Things like Roberts Rules are used for a reason. I might add that the constitution seems to have adequate methods for removing objectionable senior members by the rank and file. But the super majority rules and sometimes the losers can get pretty testy. Gary R. The problems seemed obvious to me, from the start, and hundreds of hours of reading articles, lists and blogs have not change my opinion. I think the policy process has become politicized. This idea is based on the little that I've seen as an outsider, but I'll say it anyway because I think the nature of the problem lends itself to myopia on the part of those within the system, and obvious only to an outsider. Sidestepping the question of whether it's a constitutional issue, I see an abuse of process (or bad process): bug reports are used to decide any policy, with technical arguments overriding non-technical concerns in a way that is prone for abuse, to achieve political ends. I don't think it's malicious, but more of a habit that has evolved, possibly the result of some loophole in the process. In the systemd decision, for example, a sweeping change was justified on narrow technical grounds, and this artificially limited the scope of the discussion. Everything else proceeded from this error: the split vote, flame wars, schism, defections, GR, etc. A system that was flawed from the start was finally strained to the breaking point by an external forcing function, consisting of massive software corporations leveraging their contribution to the repository by exploiting Debian's biggest weaknesses: it's governance flaws and its dependence on loose package coupling. Mark Shuttleworth's concession speech, to me, perfectly symbolizes this process of corporations using Debian as a business battleground. If there's any validity to this idea, then I think the way to solve it is to work back to the cause, be it policy or constitution, and take measures to de-politicize technical decisions, and provide a mechanism for deciding non-technical policy. Some way to give equal (or greater) weight to non-technical policy
Re: Installing an Alternative Init?
On 11/11/2014 12:07 PM, Laurent Bigonville wrote: Le Tue, 11 Nov 2014 07:42:33 -0500, Tanstaafl tansta...@libertytrek.org a écrit : On 11/10/2014 6:18 PM, Michael Biebl bi...@debian.org wrote: Am 11.11.2014 um 00:14 schrieb Miles Fidelman: Ok, then explain to me the procedure for running the installer in such a way that systemd is never installed, thus avoiding any potential problems that might result from later uninstallation all the dependencies that systemd brings in with it. Please be specific. What problems of of dependencies are you talking about? Please stop bring up irrelevant questions and address the question being asked. This does require you to at least understand and acknowledge the difference between a *clean* install, and installing something one way, then having to uninstall a primary piece and replace it with something else. The two are not the same, and no amount of you trying to act as if they are will change the fact that they are not. There are no functional differences between an installation with sysvinit-core out of the box or an install where sysvinit-core is installed later, this is a fact. Allowing the user to choose this at install time from the interface is a nice to have feature (wishlist bug) not a RC bug like you were claiming earlier. There is a potential practical consequence of not advertising an init alternative during setup. It makes users less likely to be aware of it, or even aware that the init system has changed. They won't know they lost the choice they didn't know they had. Capisce? They won't know, that is, until it bites them somewhere down the line. Then they won't know where to look or who to blame, and will blame Debian. Installation time may be only means that most users (like me*) ever would learn about it. * Install instructions? We don't need no stinkin' instructions -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462490e.4040...@ix.netcom.com
Re: Installing an Alternative Init?
On 11/11/2014 02:16 PM, Brian wrote: On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote: On 11/11/2014 12:07 PM, Laurent Bigonville wrote: There are no functional differences between an installation with sysvinit-core out of the box or an install where sysvinit-core is installed later, this is a fact. Allowing the user to choose this at install time from the interface is a nice to have feature (wishlist bug) not a RC bug like you were claiming earlier. There is a potential practical consequence of not advertising an init alternative during setup. It makes users less likely to be aware of it, or even aware that the init system has changed. New users do not need to be be aware of all the background to the choosing of a default init. No advertisement is needed. By definition, they do not care. They want Debian. Please let them have it. They will not care by definition only if they are not aware of the change, and most won't be aware unless they are informed during the installation. They won't know they lost the choice they didn't know they had. Capisce? What choice have they lost? They lost an *informed* choice. I think the installation program should not take sides but just inform the user. A choice that the user is not aware of is the same as no choice, and is potentially coercive and disrespectful. It makes Debian seem partial to Red Hat's business plan to take over the Linux ecosystem. Whatever it was, it didn't exist as you imply in Wheezy. It wasn't an issue in Wheezy because the default init option had not changed from the previous release, and any release before that. They won't know, that is, until it bites them somewhere down the line. Then they won't know where to look or who to blame, and will blame Debian. What bites them? Individually, probably something that requires sysvinit or one many core services that got replaced. Collectively, getting trapped by vendor lock-in. In both cases it could be the result of users being steered to the default init by the installation program, leaving alternatives to rot. Installation time may be only means that most users (like me*) ever would learn about it. * Install instructions? We don't need no stinkin' instructions Reading? You are right. Who wants it? Just spew out nonsense and hope nobody notices. Isn't that where the dumbed-down install is headed? Don't worry about the details silly, Windows tells you when it's time to reboot. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462ef82.5010...@ix.netcom.com
Re: Installing Android development software
On 11/09/2014 12:50 PM, Steve Greig wrote: I thought I would try and build an Android app and see that you have to download and install some software: adt-bundle-linux-x86_64-20140702.zip Before doing this (I often find installs go wrong) I was wondering if it is possible to do it using apt which I have had some success with. Only needed to setup i386 arch and ia32-libs, and a few others. Look for a recent guide on setting up the ADT bundle on Wheezy. Would be very grateful for any insight into this. Basically I don't really know how to see what software is available to me via apt. I am running Wheezy. I've not had any problems, but you might what to look at Android Studio beta if your app is already based on gradle or you don't like eclipse. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545fb4b2.2070...@ix.netcom.com
Re: useradd segmentation fault
On 11/07/2014 09:04 PM, Joris Bolsens wrote:
Ran into a bit of a strange error with useradd today,
whenever i run useradd I get a Segmentation fault.
I tried running fsck as i read it might be due to corrupt filesystem, but that
didn't report any problems.
I reinstalled the passwd package, also to no avail.
I ran an strace and it seems it cannot allocate memory, which is strange as it
is running as a vm on a machine with 32gb of ram,
and is provisioned to use whatever it needs and has 2gb reserved to it, not to
mention that top shows only a fraction of that being in use.
I recently added ldap integration if that matters at all,
although none of the other VMs seem to be having issues with this
(granted the others are running CentOs, this being the ldap server)
Output of strace:
rt_sigaction(SIGPIPE, {SIG_DFL, [], SA_RESTORER, 0x7f259c6461e0}, NULL, 8) = 0
No idea, but why are you using realtime (rt_*) system calls?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545d9b70.1060...@ix.netcom.com
Re: useradd segmentation fault
On 11/07/2014 11:29 PM, Joris Bolsens wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No idea, that's just what i got when I ran the command, I left out a bit at the top that did the ldap lookups, that all looked find and didn't want to include that as 1) dont think it's relevant and 2) contains some sensitive data (usernames and such), do you think that could have something to do with it? Well I think yes if that's what you are doing, Linux realtime support is still experimental -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545da752.3040...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 11/02/2014 05:17 AM, Joel Rees wrote: On Sun, Nov 2, 2014 at 5:35 PM, Jonathan Dowland j...@debian.org wrote: I don't think we have universal agreement that systemd violates the (rather nebulous) (Well, engineering principles do tend to _appear_ nebulous, I suppose.) To a lot of engineers as well. :( UNIX philosophy, True. Kind of like there was a time when Newton's description of gravity was not universally accepted. I wouldn't go as far as conflating natural and applied sciences. Unix philosophy is just a verbal description of the ways that principles of engineering apply in software. It is not yet well formulated. I'd say it's more of an application of computer science that works for academia and internet projects, but maybe not so well for industry. Projects out of industry tend to be monolithic, for various reasons, but most use modular Unix components. It's a good symbiosis and I don't want to discourage it by sounding dogmatic about Unix philosophy. This applies to systemd as well. Modularity once looked like the paradigm, but we discovered that modularity was also not easy to get our hands on. Lots of ways to partition a design into modules, even given the focus on character processing and use of filters in pipes. Objects, patterns, etc., and we keep finding new ways to look at the principles, and we keep finding contexts in which those ways of looking at the principles don't apply. Good design is as much an art as a science, and most of the principles are communicated by tradition. Each side dressing up their arguments with jargon just adds to the confusion. This article says much better than I ever could: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ It should be required reading for any participant in a systemd thread. at least any more egregiously than the kernel, Well, we know the kernel is significantly more monolithic than it might be. Part of the reason Linus still has work to do is that it takes time to figure out how to partition the kernel into modules that work well with each other. See http://www.realworldtech.com/forum/?threadid=65915curpostid=65915 Getting it running was important, once people started using it. Now the devs spend a lot of their time trying to find new ways to make the kernel conform to principles of engineering. If I understand what Linus is saying there, a lot of it is hardware limitations, and he has no choice. huge snip -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54565187.5030...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 11/02/2014 12:46 PM, Peter Nieman wrote: On 02/11/14 16:45, Marty wrote: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ It should be required reading for any participant in a systemd thread. Required reading because of what? In order to learn what an arrogant and insulting pamphlet looks like? I doubt that using the word dumb three times in the first few sentences is an intelligent way of convincing anybody of anything. Way more meta than I intended, but I think it's mostly because of politics, sloganeering, fanboyism and something that looks a bit like cult of mac all of which are pretty dumb by my definition, which may be why I didn't notice that. As for how the article applies to the topic, perfect Jessie would be one where subjects are discussed on their merits leading to adequate solutions for users of all supported init systems. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54567812.4010...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 11/01/2014 07:56 AM, Miles Fidelman wrote: Steve McIntyre wrote: Miles Fidelman wrote: Martin Read wrote: On 01/11/14 01:53, lee wrote: It doesn't need these code paths. The library doesn't do anything unless you do have the software actually running which the library makes useable --- at least that's what was said. Of course, not all cases are the same, yet in this case, the library shouldn't be installed unless the software it is for is installed. Gentoo and Funtoo are over there, just like they were months ago when you first started complaining about systemd on debian-user. If you move over to using them instead of Debian, you'll probably be happier (because you'll have more control over what software runs on your systems and how it's configured) and the Debian maintainers will probably be happier (because there will be one fewer person haranguing them for refusing to embrace combinatorial explosion). Everyone wins. Right. This sounds more and more like we're going to rewrite the rules, and if you don't like it, we're taking our ball and going home. Various people have tried to explain how a binary distribution like Debian works (build packages with all options included by defauls) and how shared libraries work on Linux (all the libraries need to be there to satisfy symbol resolution at run time, even if none of the code is ever used). When those explanations fell on deaf ears, people have resorted to analogy. That was clearly a waste of time too. These are standard rules that have existed for many years, there is no rewriting going on at all. Instead, it seems there are people who won't, or don't want to, understand explanations when given. For people who claim to have technical backgrounds, that's a surprising (and very frustrating) problem. Yeah... the Unix way... which systemd and it's pieces violate in so many ways. Miles Fidelman I think Debian didn't change the rules, but upstreams using an unprecedented amount of package coupling used the rules to their advantage, changing the game. To tie this back to the *nix way, the packaging and conflict resolving systems were unprepared because they were designed around modularity. They were not prepared to handle this. Policy 9.11 (interesting number) seems to have anticipated it, however. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5454f648.1030...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 11/01/2014 10:00 PM, Scott Ferguson wrote: On 02/11/14 12:19, Frank McCormick wrote: On 11/01/2014 08:58 PM, Scott Ferguson wrote: For the purpose of education not to fan silly semantic pedantics. On 02/11/14 05:24, Miles Fidelman wrote: snipped Second, we're not talking about vaguely unixy - we're talking about a well developed philosophy of designing things that dates back to Ken Thompson, et. al (c.f., The UNIX Programming Environment,or http://en.wikipedia.org/wiki/Unix_philosophy). I keep wondering if that's a cause of confusion. Why does the Linux kernel, GNU, and the rest of userland*have* to be done the UNIX way?? I keep hearing this assertion, but neither Linus Torvalds, or RMS/seem/ to support it's requirement. Could you expand on why this is a requirement from the people that produce's point of view?? In this interview he makes it clear he does not think the entire Linux system has to be done the UNIX way. *Which does not answer my question.* I'm well aware that neither RMS or Linus do not advocate that Linux, kerenel and userland are UNIX, not have to be the UNIX way. I'm asking why people keep insisting that systemd is bad *because it's not the UNIX way*. It sounds like a strawman - but I'm giving the benefit of the doubt and asking for clarification. I'm uncertain of your intention/comprehension of the question Frank - but your response is not an answer to my question. My answer is systemd doesn't have to be done the Unix way. It's a red herring. Nobody complains about Android not being the Unix way. It's irrelevant. The relevant question is should Debian be implemented the Unix way, or should one software suite gobble up so many modular services that Debian is no longer Unix-like in any meaningful way? snipped to try and retain relevance Kind regards -- Turns out you can't back a winner in the Gish Gallop ~ disappointed punter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54559317.40...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 10/29/2014 06:53 AM, Laurent Bigonville wrote: Le Wed, 29 Oct 2014 00:52:54 -0400, Marty mar...@ix.netcom.com a écrit : On 10/28/2014 05:10 PM, Christian Seiler wrote: Am 28.10.2014 20:53, schrieb Marty: This just being one example of context being leaked. Some of this context could be cleaned up if uuidd were setuid root (and not setuid uuidd), but not all of it necessarily. From what you write it's not clear if a) there is an unavoidable security threat in all use cases, Not necessarily a security threat, it could also just be unexpected behavior due to leakage of context. The problem is that there are so many possibilities of things that could happen in certain circumstances with things like this that it's not clear as to what the security implications are going to be, not that there necessarily are any. and b) there is no way the systemd replacement can co-exist with on-demand UUID in the same executable. No, it could, no question. Then if I read you correctly, the old mechanism may not work with a promised future kernel security feature, but could be working securely now in some use cases, albeit as a hack. I was never talking about future kernel versions. I was talking about lots of stuff that is still in the *current* kernel that incurs state that is passed on to children of processes. To name a few off the top of my head, that might cause problems, depending on the circumstances: - capability bounding set (cannot be directly escaped for a process, even as root) - SELinux context (depending on transition rules, maybe can't be escaped and certainly would need a specific rule for uuidd from every daemon that uses it) - seccomp syscall filters (usually can't be reset, even as root) - prctl(PR_SET_NO_NEW_PRIVS) (can't be reset) - nice priority (needs root to reset) - cgroup membership (needs root to reset) - PID namespace (if init of a PID namespace dies, all processes inside that namespace get SIGKILL) - and that's just off the top of my head So granted, these are problems that need to be fixed, but they are in Wheezy then people are already living with them and probably doing OK. Problems are identified, some people wants to solve them. And we shouldn't solve them, because of what? There is a difference between being OK and being technically correct. Now I'm not saying that all of them are necessarily a problem, it really depends on what the concrete circumstances are. But the issue here is that for a general-purpose library that may be used by different services that may be subject to any number of the aforementioned contexts. Could they have instead made the library call a no-op if systemd is installed, instead of requiring the new dependency? People not using systemd would not be any worse off than currently, and they would likely be small in number. For those, the risk of using the old hack should be weighed against the risk of a new, complex, and relatively untested solution, relative to its size. Should the user be able to decide that? You still need to have something handling the systemd activation protocol for systemd users. You either need to reimplement in the executable (code duplication is bad) or depends against the library that does that for you... And the later is the way (lot of) upstreams have chosen. Leaking context information seems more a problem to me that using code that actually does NOTHING if systemd is not used as PID1. (Did you actually looked at the code?) I had not thought of the non-PID1 case, or believed the init script could cover that it. As for the buggy hack, I don't propose reverting it because I assume upstream had a good reason to not to have a deprecation period. I'm just asking a question about backwards compatibility and using it as an example. The users who actually care are still free to revert patches and/or drop configure flags to remove systemd socket activation support. So instead of shipping something that kind of sort of works in many cases now but that may cause some weird, unexpected and probably really hard to debug problems later, the authors decided to drop this logic and say: on systems without socket activation, it just has to always be started. uuidd, if always started, still works on those systems. If that's right, then the way it was removed is the problem. As I said in my earlier mail: even if there had been no possibility to do a safe and secure on-demand activation (no init system with socket activation available) I still would have said that removing this on-demand hack and always starting uuidd would have probably been the best solution. By problem I meant what I consider the problem of not having an overlap between old and new solutions, and no deprecation period or warning. I don't argue that it should not be corrected. My point was more of a policy and design strategy issue. There is NO functional change at all
Re: Suggestion for systemd and /usr on seperate partition
On 10/30/2014 10:14 AM, Jonathan Dowland wrote: Hi, On Thu, Oct 30, 2014 at 10:27:50AM +0100, Hans wrote: I am using systemd and I have /usr mounted on a separate partition as well as /var, /home, /boot and /. Additionally /usr, /var and /home are luks encrypted. If you want this to work, you need to ensure that /usr is mounted by the initramfs. That means moving the cryptsetup prompting into the initramfs if it isn't there already. I do not know to what extent the Debian tools for building an initramfs, or the cryptsetup stuff, will help you to get this set up right. I thought about this problem. Might it be possible, to change systemd in that way, that it will start after all partitions are mounted? I know, it must be done in the source code, but as I am no coder, I cannot do it myself. Not really, since systemd is the first thing started by the kernel, with one exception: work done in the initramfs. The point of the initramfs is to ensure that whatever the kernel needs to mount the root filesystem is available to it, so that can be done prior to starting init. If you are splitting the root partition up by having a separate /usr, then the initramfs needs to ensure /usr is available too. It might be possible to enhance the cryptsetup/mkinitramfs stuff in Debian to make this easier. I'm still learning about this. Can you help me make sense of the following link, which seems to be saying the problem was solved long ago? http://lists.freedesktop.org/archives/systemd-devel/2011-March/001499.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54525ef6.3060...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 10/30/2014 04:29 AM, Laurent Bigonville wrote: Le Thu, 30 Oct 2014 02:24:27 -0400, Marty mar...@ix.netcom.com a écrit : On 10/29/2014 06:53 AM, Laurent Bigonville wrote: Le Wed, 29 Oct 2014 00:52:54 -0400, Marty mar...@ix.netcom.com a écrit : [...] By problem I meant what I consider the problem of not having an overlap between old and new solutions, and no deprecation period or warning. I don't argue that it should not be corrected. My point was more of a policy and design strategy issue. There is NO functional change at all, what was working before is still working now. The only difference is that you have an extra daemon running from the start (and running in a clean context). The deprecation issue would not apply to Jessie, just some legacy code. I'm not following you here The thread has taken some detours (and my part started in another thread) but my original question was why wasn't the setuid functionality deprecated and allowed to remain for backwards compatibility reasons, for a transition period, after adding the script? The daemon here on my machine is using 1224KiB of resident memory, this is nothing on modern machines. I personally don't even see why we are discussing this tbh. I don't know about you, but I am here because I am trying to decide if this is a case of accidental vendor lock-in and more broadly if there is a backward compatibility policy issue that encourages it, or if this is an isolated instance. There's also the matter of the missing init script, doubts about init script support, the freeze, the GR, the vote, and questions about deprecation policies in general, as background. At this point I'm willing write it off as undecidable, at least by me. :) There is a /etc/init.d/uuidd initscript currently in jessie, see: https://packages.debian.org/jessie/amd64/uuid-runtime/filelist http://sources.debian.net/src/util-linux/2.25.1-5/misc-utils/uuidd.rc.in/ And it has always been clear (at least to me) that all the packages must continue to support sysvinit and not remove any LSB initscripts for the jessie release. From sifting through archives, it's becoming clear that upstream did provide a deprecation period, of 6 years it seems, between the time the script was added and setuid was removed, but the script was only added to Debian recently, which is why I couldn't find it in my repos or on the Debian package search page. It looks like the script slipped through the cracks, but no signs of conspiracy. :) Thanks for helping me sort this out. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545310e2.7050...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 10/27/2014 12:15 PM, Christian Seiler wrote: Am 27.10.2014 15:05, schrieb Dimitrios Chr. Ioannidis: Btw. the commit you are referencing just updated the init script, the change in libuuid was done over 2 years ago: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/libuuid/src/gen_uuid.c?id=ea4f8845f0241c714f9487ece5bb6900fc18a9e0 That all said: I can understand why the util-linux people wanted to get rid of the old on-demand mechanism: it's potentially error-prone and may leak context from the program using libuuid into uuidd. Say, for example, you put the daemon using libuuid into a cgroup - not with systemd, but with for example cgconfig. And then that daemon starts uuidd because it's the first to request a UUID. uuidd will then live in the same cgroup as the daemon. If the administrator then uses the 'freezer' cgroup to atomically stop the entire service that initially started uuidd, then uuidd will get stopped alongside with it as 'collateral damage'. And then other services using it will block because uuidd is still running but they have to wait until it responds again. This just being one example of context being leaked. Some of this context could be cleaned up if uuidd were setuid root (and not setuid uuidd), but not all of it necessarily. From what you write it's not clear if a) there is an unavoidable security threat in all use cases, and b) there is no way the systemd replacement can co-exist with on-demand UUID in the same executable. I'll assume no in both cases for now. I'll leave alone the issue of whether the script-workaround is a complete functional replacement of the library version. Then if I read you correctly, the old mechanism may not work with a promised future kernel security feature, but could be working securely now in some use cases, albeit as a hack. If that's right, then the way it was removed is the problem. Now, this probably will not have been a problem in your specific case. So yes, you lost a feature there. But put yourself in the perspective of the developers of util-linux: - drop an error-prone and potentially security-relevant mechanism for on-demand startup - add support for on-demand startup that will work on a large number of installations (systemd being quite prevalent already then) - on all other installations: it will now have to be started from the very beginning Obviously, the latter part is not optimal for you, but uuidd will keep working on your system, so I don't see what the huge problem is. Except that the work around won't be in Jessie AFAICT. The parent poster has to waste time tracking it down the script and background information, assume it's untested, hope that it works, and hope that the relevant messages explaining it have not expired from the mailing list archives (util-linux-ng). He's mostly on his own, fixing a problem that probably should not have happened in the first place, if my hypothesis is correct. Even if the script were supplied and works as advertised, it still could mean upgrade breakage, depending on the use case. The possibility of vendor lock-in is hard to ignore in cases like this. I think this one could be related to the bluez coupling issue, but I have not explored that possibility. My concern would be how many backwards-incompatibility cases like this are lurking in Jessie? Are more being added each day? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544ff450.6080...@ix.netcom.com
Re: [Solved] New install: root account is locked, starting shell
On 10/28/2014 11:14 PM, tjr0...@gmail.com wrote: Sent from my iPhone Delete the root password x in /etc/passwd -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54506bfc.8080...@ix.netcom.com
Re: Perfect Jessie is something like this...
On 10/28/2014 05:10 PM, Christian Seiler wrote: Am 28.10.2014 20:53, schrieb Marty: This just being one example of context being leaked. Some of this context could be cleaned up if uuidd were setuid root (and not setuid uuidd), but not all of it necessarily. From what you write it's not clear if a) there is an unavoidable security threat in all use cases, Not necessarily a security threat, it could also just be unexpected behavior due to leakage of context. The problem is that there are so many possibilities of things that could happen in certain circumstances with things like this that it's not clear as to what the security implications are going to be, not that there necessarily are any. and b) there is no way the systemd replacement can co-exist with on-demand UUID in the same executable. No, it could, no question. Then if I read you correctly, the old mechanism may not work with a promised future kernel security feature, but could be working securely now in some use cases, albeit as a hack. I was never talking about future kernel versions. I was talking about lots of stuff that is still in the *current* kernel that incurs state that is passed on to children of processes. To name a few off the top of my head, that might cause problems, depending on the circumstances: - capability bounding set (cannot be directly escaped for a process, even as root) - SELinux context (depending on transition rules, maybe can't be escaped and certainly would need a specific rule for uuidd from every daemon that uses it) - seccomp syscall filters (usually can't be reset, even as root) - prctl(PR_SET_NO_NEW_PRIVS) (can't be reset) - nice priority (needs root to reset) - cgroup membership (needs root to reset) - PID namespace (if init of a PID namespace dies, all processes inside that namespace get SIGKILL) - and that's just off the top of my head So granted, these are problems that need to be fixed, but they are in Wheezy then people are already living with them and probably doing OK. Now I'm not saying that all of them are necessarily a problem, it really depends on what the concrete circumstances are. But the issue here is that for a general-purpose library that may be used by different services that may be subject to any number of the aforementioned contexts. Could they have instead made the library call a no-op if systemd is installed, instead of requiring the new dependency? People not using systemd would not be any worse off than currently, and they would likely be small in number. For those, the risk of using the old hack should be weighed against the risk of a new, complex, and relatively untested solution, relative to its size. Should the user be able to decide that? So instead of shipping something that kind of sort of works in many cases now but that may cause some weird, unexpected and probably really hard to debug problems later, the authors decided to drop this logic and say: on systems without socket activation, it just has to always be started. uuidd, if always started, still works on those systems. If that's right, then the way it was removed is the problem. As I said in my earlier mail: even if there had been no possibility to do a safe and secure on-demand activation (no init system with socket activation available) I still would have said that removing this on-demand hack and always starting uuidd would have probably been the best solution. By problem I meant what I consider the problem of not having an overlap between old and new solutions, and no deprecation period or warning. I don't argue that it should not be corrected. My point was more of a policy and design strategy issue. Obviously, the latter part is not optimal for you, but uuidd will keep working on your system, so I don't see what the huge problem is. Except that the work around won't be in Jessie AFAICT. I didn't check, but if Jessie's uuidd doesn't start automatically on non-systemd systems, then this is clearly a bug and a bug report should be filed. The parent poster has to waste time tracking it down the script and background information, assume it's untested, hope that it works, and hope that the relevant messages explaining it have not expired from the mailing list archives (util-linux-ng). He's mostly on his own, fixing a problem that probably should not have happened in the first place, if my hypothesis is correct. There's a reason why Jessie is still testing and not yet stable, and if you do find bugs, please report them so they may be fixed. Even if the script were supplied and works as advertised, it still could mean upgrade breakage, depending on the use case. In what way? If somebody had uuidd installed in Wheezy and then upgrades to Jessie, there should be no breakage if the script is also updated, because then uuidd should always be started. One way, speculatively, is a failed library call during app initialization causing
Re: Who's locking down the code?
On 10/27/2014 10:14 AM, Dimitrios Chr. Ioannidis wrote: Στις 25-10-2014 20:30, goli...@riseup.net ÎγÏ�αψε: On 2014-10-25 12:14, Laurent Bigonville wrote: golinux wrote: Would appreciate comments on this observation: Look at the source code (while you're at it, note who are the upstream maintainers of util-linux). Even they (so far) allow compilation without systemd. It is Debian who are introducing systemd dependencies even where it is actually optional in the upstream source. If upstream is allowing choice, why is Debian cutting it off? Maybe I'm missing something . . . golinux The fact that an executable is linked against a systemd library doesn't automatically mean you have to run systemd as PID1. This is especially true for the sd-daemon and sd-journal libraries in this case. Laurent Bigonville I have heard that argument before. I counter that it's about more than PID1. It seems that even having systemd libraries etc. is a little like being somewhat pregnant - precursors to a little bundle of joy to be delivered at a later date when the PTB see fit. In other words, a trojan of sorts that will come to bite us. Sorry, not much trust these days . . . :( I tend to agree with you golinux. We'll maybe forced to use systemd, if we don't want to start uuidd daemon from the start, cause of this commit in util-linux, libuuid[1]. [1] http://www.spinics.net/lists/util-linux-ng/msg09698.html Regards, -- Dimitrios Chr. Ioannidis It may have started in 2009 with this util-linux message: Anyway, do we really need to support suid uuidd? What about to drop all this stuff and require that uuidd has to be started by init scripts only? What about to drop exec-from-library at all? http://www.spinics.net/lists/util-linux-ng/msg05967.html Debian bug report in June 2014: commit ea4f8845f0241c714f9487ece5bb6900fc18a9e0 Author: Petr Uzel petr.u...@suse.cz Date: Thu May 3 21:01:59 2012 +0200 libuuid: don't exec uuidd Executing the daemon from the shared library is not quite elegant solution. Drop this functionality and require uuidd (should it be needed) to be started from the initscript or by socket-activation. References: http://www.spinics.net/lists/util-linux-ng/msg05967.html ... The solution would be to ship the uuidd sysvinit script which would give a way to start the uuidd. This script creates the directory as needed. (Note: this script is already available in the current v2.20.1. See misc-utils/uuidd.rc. The script is just not shipped in the current package.) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719759#10 Finally from link cited in the parent message, in July 2014: You now need systemd (socket activation) to use uuidd on demand. I looked and did not find the script. I still don't know what the original problem was (although I didn't dig very deep). In any case I don't see how the script is more elegant than the original solution. Can anyone explain what's going on here? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544eee30.5090...@ix.netcom.com
EFI SecureBoot and Trusted Computing in Debian
This is the best I could come up with so far. I have found my lance and my rickety but pompous horse. Did anyone see where the windmills went? (cc'd to -user) --- What I call the manifesto [1] claims that UEFI SecureBoot is needed in a post Snowden World. If Debian's freedom of choice in init systems resolution fails, what are the chances of getting enough volunteers to sustain multi-init support? The trap could spring. The exit door could close. The drones could finally march in lockstep. If PID 1 is owned by a central Linux authority, is there any reason to think the rest of the manifesto's ambitions will not be achieved? The authors provide the hook: a unified solution for operating systems that manage themselves, that can update safely without administrator involvement. No more worries about binary blobs or untrusted users, but trustees who play by the rules might be allowed in the Potemkin village to help spiffy things up. I wonder if this is the logical conclusion of push technology? Show the man your compute license before boarding, but if you missed your last payment or tampered with anything, that's why you got the kill switch. Don't forget to safely recycle your disposable device. I don't see anything in it for Debian, which has its own crypto-signed archives and distributed development, and I don't think the post Snowden lesson is to trust centralized authority and put all your eggs in one basket. But as a mere user, my opinion doesn't count for much. We can cry on each others shoulders in our private forums, but don't stand in the way of progress or ask who's behind it all. If you make it past the censors, you just might find yourself under house arrest. [2] It's obvious that there is a compelling interest in trustworthy personal surveillance devices, but it's not about the user's interest, nor the user's trust. Where would I file the Debian bug to report that freedom has been deprecated? - [1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html [2] http://www.newsweek.com/assange-google-not-what-it-seems-279447?piano_d=1 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544c0245.5040...@ix.netcom.com
Re: If Not Systemd, then What?
On 10/20/2014 03:45 PM, Patrick Bartek wrote: After much vitriolic gnashing of teeth from those opposed to systemd, I wonder... What is a better alternative? And it can't be sysvinit. One that doesn't divide the FOSS world. We have enough challenges without that. Yes. Syvinit still works, but it is after all 20 years old. It's been patched and bolted onto and jury-rigged to get it to do things that weren't even around (or dreamt of) at its inception. It's long past due for a contemporary replacement. Whatever that may be. Whichever one the user wants is the best. The users should decide, individually and collectively. The distro should be the testbed for new ideas, with users trying out and choosing solutions that work best for them. Debian should not make that choice for users. Upstreams should not make that choice for Debian. This is official Debian Policy but some people seem upset about it. I don't understand antipathy toward user choice, especially here. I sometimes wonder if they have lost sight of the purpose of FOSS, which would be sad, because they (especially volunteers) have given us so much in the name of software freedom. They have changed the world. I hope this just a misunderstanding that gets cleared up after the dust settles and everyone starts talking again, instead of just yelling at each other. I hope some people change their minds about the importance of user choice. I hope Ian Jackson stops being bitter. :) So, what would you all propose? For a server? Or for a user desktop? Or something that fulfills both scenarios? And why? We all should be able to propose our ideal solution with a reasonable expectation that if it's a good idea, and somebody does the work, it could be adopted and help other people, without being unduly hindered by a software bundle laying exclusive claim to PID 1. That is the unique gate-keeper spot in all systems, and it's probably why the policy pays special attention to it. That button belongs to me, the user. Hands off my computer at its most vulnerable spot. Just wondering. Me too. B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5445bf9f.2060...@ix.netcom.com
Re: kworker writes to disc every 5 seconds on battery
On 10/18/2014 04:47 PM, Teresa e Junior wrote: Hello! I have noticed that my current setup of Chrome writes to disc every second. While hunting for the problem, I have found an old bug report on Google Code about this, and from my tests I concluded my solution for now would be to run Chrome with its profile and cache in a tmpfs. Problem solved, or rather, not solved at all. In a laptop running on battery, it would be desirable to let the HD spin down a bit sometimes, right, right, right? Well, I think so, so after optimizing the settings for some applications, I have found these two spoiled brats who write to the disc frequently, and never let it sleep: jbd2/sda3-8 and kworker/u8:0. The jbd2/sda3-8 problem seems to have been solved by remounting the partition with commit=60, so no more journal writes every five seconds. But what about this kworker/u8:0 lad? Who is he, and what is he doing? I know it is a kernel worker, but not more than this. After some search, I found someone saying I should run: `echo l | sudo tee /proc/sysrq-trigger', which outputs some nice information, but which I could not understand. So I have asked my mother, because she was the person who taught me how to walk, if she could read it, and was left puzzled as to how there could be something even our ancestors couldn't understand. They understood once, as students, but then it got too big and complicated, and they didn't have time to keep up. They forgot to KISS (qv). Try looking for everyone with the same problems with the laptop model and electronics, and remember that most laptops are designed for Windows, which often makes it hard to solve problems like yours. Is there a way for me to know what is kworker/u8:0 writing to the disc A printk in the kworker thread? but be careful, may need mom's help with that. every five seconds? Also, if it's not a bother, could someone test if this also happens there? The commands I run while on battery were: echo 1 | sudo tee /proc/sys/vm/block_dump tail -F /var/log/debug | grep -v dirtied echo 0 | sudo tee /proc/sys/vm/block_dump And by the way, my kernel is 3.15.10-zen-686-pae Thank you! Teresa e Junior -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5443cd56.5010...@ix.netcom.com
Re: GR proposed re: choice of init systems
On 10/19/2014 01:25 PM, Tanstaafl wrote: On 10/17/2014 3:42 PM, Ric Moore wayward4...@gmail.com wrote: The fun part will be to see who actually steps up to the plate to do all of the extra work. Especially amongst all of those pledged seconds. I hope someone is keeping a list. :) Ric From what I read, it will be one all debian devs (package maintainers) to fully support all supported init systems in debian in any packages that they maintain. I don't see anything like that in the resolution or discussion. The resolution prohibits exclusive dependence on a PID 1 init, ie it doesn't (directly) enforce multi-init, but it prohibits init tying or mono-init, I guess you could say. See the -vote discussion for the full explanation. I see nothing wrong with this. It isn't forcing anything on anyone, in that any debian package maintainer is free to step down (stop maintaining debian packages) any time they want. It is simply a rule of being a debian package maintainer. It's also been Debian Policy for ages (9.1.1). The resolution may reinforce a policy seen as obsolete by some devs, but changing it requires a 2/3 vote which means that this doesn't really do much, and that or similar arguments were primary objections, if I followed it correctly (and as a user seeing for the first time how Debian sausages get made). What it allegedly does, however, is clarifies policy over an application case where there seems to be lots of confusion and debate, making it a candidate for resolution. This point was generally not contested. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54440082.2080...@ix.netcom.com
Re: Conflict of interest in Debian
On 10/16/2014 08:41 PM, Ric Moore wrote: But, I consider it idiotic to bash Red Hat as ~anyone~ with the guts can do what Bob Young did. Just gather some talented people together around a kitchen table and create your own distro. That is perfectly legal and now they are worth billions, by starting exactly from that point. :) Ric I agree and appreciate your stories, which are an important part of the history of Linux. I'm trying to keep the issue hypothetical because a) I'm not a member b) it's a question and concern, not an accusation nor a conviction, and c) otherwise, it could come across as innuendo about companies or individuals in an environment that it already overheated. That's a bigger concern that the original question so it defeats my purpose. I'm also satisfied that I've given it (maybe more than) enough attention in this forum, and I understand now that this is the wrong place to pursue it anyway. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54408d5e.2020...@ix.netcom.com
Re: Conflict of interest in Debian
On 10/15/2014 04:19 PM, Ric Moore wrote: On 10/15/2014 07:08 AM, berenger.mo...@neutralite.org wrote: Le 15.10.2014 12:09, Brian a écrit : On Wed 15 Oct 2014 at 10:41:12 +0200, berenger.mo...@neutralite.org wrote: Le 15.10.2014 09:11, Jonathan Dowland a écrit : On Wed, Oct 15, 2014 at 12:51:07AM -0400, Steve Litt wrote: Check out what single company has 30% of the gatekeepers. Surprise, surprise. Damned for their success. We want Linux to be successful, but woe betide any company that actually gets us there... Maybe you want. But I think that most users just want it to work fine and efficiently, which does not necessarily imply being sold massively around the world. He's doing some of the work on Debian; others work with different distributions. They get what they want. Users get what they want. Everyone's a winner. :) Maybe. But, when someone tries to sell stuff a lot, to have a big market share, then that guy must take a large target, which leads to systems which might become less stable or less efficient. And if that guy want to keep his market, then he'll have to avoid people escaping his stuff, this is why vendor locks exists. Definitely, I hope that Debian won't take that road. It it does, then, I'll switch. I'm taking a look at netBSD, even if I guess that I'll have a hard time being successful in feeling as comfortable with it than with Debian. I don't know what you all do to get paid in order to pay bills and/or raise a family, but working for Red Hat is not a bad gig. This is fortuitous! Not a bad gig at all. I'm sure some soreheads think that we debated WORLD DOMINATION during lunch, or how to screw over Debian, but sadly we mostly discussed what was the Right Thingtm Do you mean, job-related ethics? to do there just as we do on this list. I'm glad you replied because you're just the person to query. When you discussed job-related ethics at lunchtime, did the subject of conflict of interest ever come up, regarding voting in Debian? If it's impossible to imagine, then consider a purely hypothetical case. A developer is working on a package that could get widespread adoption within Debian, but some kind of technicality stands in the way, requiring a vote. As an employee, is there a conflict if he votes? I know I'm the joker on this list but now I'm serious. serious smiley would go here After all, everyone at RedHat had been a user first, before landing a paying job. So, to everyone heaping scorn on RedHat, go here: http://jobs.redhat.com/ So you mean, the place for people with inferiority complexes? :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543f0b24.2020...@ix.netcom.com
Re: piece of mind (Re: Moderated posts?)
On 10/15/2014 07:54 PM, Jonathan de Boyne Pollard wrote: snip * http://freedesktop.org/wiki/Software/systemd/hostnamed/ * http://freedesktop.org/wiki/Software/systemd/timedated/ * http://freedesktop.org/wiki/Software/systemd/localed/ * http://freedesktop.org/wiki/Software/systemd/logind/ These RPCs are supplied by server daemons, that communicate with client programs (e.g. the aforementioned gadgets) over D-Bus. The operating system specific stuff, such as exactly what configuration file contains the static hostname on the system, is intended to be contained within these server daemons. All that a client knows is that it makes the set the static hostname RPC call, and some server does the necessary work whatever that is. The Debian systemd package comes with its own implementation of these server daemons. Contrary to the recommendation of the GNOME people almost three years ago, but in line with what the systemd people prefer, on Debian they aren't packaged separately and are indivisible from the remainder of the package. Did their interdependence not prevent them from being packaged separately or at least make it pointless? * https://mail.gnome.org/archives/distributor-list/2012-January/msg3.html This is what three years' worth of hoo-hah has, at its root, all been about: a packaging decision. I'm not going to summarize or re-hash the hoo-hah here. I would read it, but I think it will all be re-hashed again anyway, in one way or another, and I don't think that's a necessarily a bad thing. I thought I was keeping up with the news, but I missed most of this. Suffice it to say that there are both engineering rationales and socio-political rationales for the decision, and the major problem is logind, the systemd server daemon that provides the login API. Even though the other three somewhat are (modulo the fact that they all pick the particular choices of configuration file locations that match what other programs in the systemd package, such as systemd-machine-id-setup, use), logind is not at all severable from the rest of the systemd package, because the operating-system specific underpinnings of it (These daemons are intended to be abstracting a whole bunch of operating-system-specific non-portable stuff, remember.) target a Linux system that is running the systemd daemon and its ancillary daemons and utilities. Naturally enough snip When I remove systemd and replace it with sysvinit, it still seems to work. Can that part which is still working be refactored and turned back into a modular login package? Is this the main problem of maintaining a modular system? (It seems too simple.) Or is it likely that the main problem is (what you call) socio-political. Thanks for the summary. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543f3a86.1060...@ix.netcom.com
Conflict of interest in Debian
It seems like free software employment and market share come with increasing risk to objectivity and technical quality. It's my main concern as a Debian user, as I consider recent trends. I hope that Debian members consider an amendment to restrict voting rights for members who have a financial interest in Debian or in any project used by Debian, to promote and protect the public interest. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d0f78.7060...@ix.netcom.com
Re: Conflict of interest in Debian
On 10/14/2014 12:10 PM, Don Armstrong wrote: On Tue, 14 Oct 2014, Marty wrote: It seems like free software employment and market share come with increasing risk to objectivity and technical quality. People have to eat. Almost everyone who works on Debian has someone who pays them. It's my main concern as a Debian user, as I consider recent trends. It really shouldn't be. The biggest concern that I have is getting new contributors into Debian and keeping existing contributors from burning out. Companies paying people to work on Debian is one way of getting more contributors and keeping existing contributors happy. I hope that Debian members consider an amendment to restrict voting rights for members who have a financial interest in Debian or in any project used by Debian, to promote and protect the public interest. Everyone who contributes to Debian has an interest in what the project does, whether or not its financial. There's a reason why we're contributing, after all. People who are in positions of power in Debian are relatively open about what those interests are and who their employers are. But expecting people not to vote or participate just because they happen to be paid to work on Debian isn't healthy or sustainable. I am only concerned about the ethics of it. As an outsider I can't speak about the practicality or sustainability of a voting restriction, but I think such codes are commonplace in nonprofits. In any case I too have a concern about the long-term sustainability of Debian, but as a volunteer organization. If it's not an issue now in Debian, it almost certainly will be in the future. This illustrates a part of my concern: http://spectrum.ieee.org/computing/software/whos-writing-linux Say hello to our new bosses? That said, if despite my counter-arguments, this is something you feel strongly about, find a DD who agrees with you, write up a constitutional amendment, and get it proposed on -vote or discussed -project. It's not on topic here. Thanks, I'll consider that. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543dc16a.7050...@ix.netcom.com
Re: Conflict of interest in Debian
On 10/14/2014 12:47 PM, Brian wrote: On Tue 14 Oct 2014 at 12:06:11 -0400, Henning Follmann wrote: On Tue, Oct 14, 2014 at 11:02:10AM -0400, Steve Litt wrote: On Tue, 14 Oct 2014 08:05:06 -0400 Henning Follmann hfollm...@itcfollmann.com wrote: On Tue, Oct 14, 2014 at 07:56:40AM -0400, Marty wrote: It seems like free software employment and market share come with increasing risk to objectivity and technical quality. It's my main concern as a Debian user, as I consider recent trends. I hope that Debian members consider an amendment to restrict voting rights for members who have a financial interest in Debian or in any project used by Debian, to promote and protect the public interest. Why, what is the reason for that? Explain why they are less objective or anyone having no financial interest is more objective. You know darn well, Henning. In anything, not just Linux, not just Debian, not just systemd, when somebody has the responsibility of doing the best thing for the community or other entity, but they also have a financial stake in which way the thing goes, they have a huge incentive to vote in a way detrimental to the community or other entity. This is why bribery is a crime. Well thanks for pointing that out. But this effort can be seen as a way to tilt the voting based on one aspect. And this being _systemd_. Now a group has identified that another group with financial interest is more likely to vote for sytemd. So lets disenfranchise those. That is equally bad. And second financial interest != bribery. This is a very distorted view. My work is based on debian as a development platform. So I do have a financial interest in debian being a stable platform. So I shall be disenfranchised? The depths are really beginning to be plumbed. We have a proposer of an resolution linking financial gain with the work people do in their free time to give us a free OS. This is rapidly followed by a seconder who has found another bandwaggon to jump on. All this is supposed to be for the benefit of Debian. When I started using Debian it was a hobby toy and something like this would never have come up. Now I have a hard time convincing myself that individual volunteers will ever again have that role or voice. The invisible hand of the market should not be the guiding force in Debian. Give me swearing in posts rather than innuendo and attempted character assassination of a group dedicated workers. I've seen some of that too, and it's sad, as well as undeserved, but it's the kind of dynamic that these conditions might give rise to. An honor or ethics code might defuse some of that, but I leave that for members to decide. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543dc2b5.4070...@ix.netcom.com
Re: piece of mind (Re: Moderated posts?)
On 10/13/2014 07:13 PM, Miles Fidelman wrote: Joey Hess wrote: Miles Fidelman wrote: But that is the major objection of those of us who USE Debian -- the need to do so, particularly when this concerns production servers. Sysvinit will continue to be supported on servers in Debian 8 (jessie) release of Debian. So you can continue to boot your production servers with sysvinit. A reasonably proactive admin would probably want to try out systemd (on eg, a test server) and if it causes problems for their deployment, they then have at least the year or two from when Debian jessie is released until the *next* release to file bug reports and follow up on them. Too early to say what will happen in Debian 9, but https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715#278 is not going to be overturned without a GR either. Ok... for others who are concerned, this is the punch-line from that bug report: --- From: Don Armstrong d...@debian.org To: debian-devel-annou...@lists.debian.org Subject: [CTTE #746715] Continuing support for multiple init systems Date: Thu, 31 Jul 2014 19:36:30 -0700 [Message part 1 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=278;att=0;bug=746715 (text/plain, inline)] The technical committe was asked in #746715 to address the removal of support for upstart in a package. RESOLUTION The issue of init system support recently came to the Technical Committee's attention again.[1] For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. [1] See #746715 for background. END OF RESOLUTION --- That's the kind of crystal clear commitment that helps put at least some of my concerns to bed - whether this is honored in the breach (e.g., as part of testing things) remains to be seen - but it's a very good start. Thanks for the pointer. That does leave three open questions/concerns in my mind: 1. Whether or not there's a clear statement regarding the installer - will users be presented with a clear choice of init systems during installation, or is it going to be left to folks to figure out how to work around the default installation of systemd? 2. How well backward compatibility and transition is supported during the, what seems to be inevitable, ultimate prevalence of systemd - i.e., how well systemd-shim is supported and how complete and accurate systemd's support for sysvinit scripts will turn out to be. 3. The general monolithic nature of systemd. The last is a matter of design philosophy - and potentially one of vulnerabilities to lurking bugs and security holes. For 1 2 - any pointers to equally clear statements about expectations and committments, akin to the cited resolution? I don't know if this is what you are looking for, but this might be the policy being referred to: https://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543c6f0e.1020...@ix.netcom.com
Re: debian-advocacy?
On 10/13/2014 07:14 PM, Brian wrote: On Tue 14 Oct 2014 at 08:02:28 +0900, Joel Rees wrote: On Tue, Oct 14, 2014 at 7:35 AM, Brian a...@cityscape.co.uk wrote: On Mon 13 Oct 2014 at 15:07:33 -0700, Buntunub wrote: This list is the perfect place for such things. The decision to make Systemd default in Jessie was done by the Technical Committee, not by general vote, so I guess it was decided that the whole discussion about Systemd is a bug because it was relegated to such. This is the mailing list used to discuss bugs and technical issues, is it not? I wanted so much to understand and make sense of what was being said here but gave up in the end and turned to the comfort of a book on Quantum Chromodynamics. Can I recommend a thesis on analyzing execution paths of critical processes? I'd try anything if it brought enlightenment to the post I responded to. I think he's saying systemd is one huge bug, but you turned to physics because you thought it might actually be a Hindenburg, and then got gently steered back to traditional computer science for right answer. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543c712d.2040...@ix.netcom.com
Re: implicit linkage
On 10/11/2014 12:49 PM, Andrei POPESCU wrote: On Sb, 11 oct 14, 12:19:29, Marty wrote: Could it be that a modular design for such complex tasks becomes too difficult to *do it right*? I don't know, but I think given its history, the burden of proof is on monolithic, not modular design. A better question may be whether a distributed volunteer project can do real system architecture? (Where is CERN when you need them?) Who's history, Linux' (the kernel)? :p I was thinking of Windows, but opened Pandora's box instead. :/ Couldn't it be that the fact that so many are embracing the monolithic design of systemd is a sign that the modular design was... suboptimal and nobody came up with a better one? Modular design addresses large complex system design, and it seems counter intuitive to say that higher complexity can favor monolithic design. Maybe the people embracing don't fully understand this, or just don't care. It's one of the classic debates of computer science, but for unix in particular, modular design has always been the time tested, core design philosophy. It seems ironic that just at the point where unix design superiority is enabling it to overtake Windows in some areas, we get a monolithic rewrite of the core system. In their minds, it seems, unix modularity is a bug and Windows is the model for fixing it. Components like sysvinit are dinosaurs, but modularity was the key design feature that made piecewise-replacement possible while keeping the whole modular system running smoothly. They threw out the methodology for no sound technical reason, that I can see. They replaced the Unix tool box with this: http://partsolutions.com/wp-content/uploads/2014/01/Worlds_largest_Swiss_Army_knife_wenger_giant_knife.jpg It is no coincidence that it promotes vendor lock-in extending from boot to DE. It's a predictable result of their monolithic design philosophy. Looking at the bright side, now that Debian is in the business of replacement monolithic OS's, let's include Cyanogenmod and Chrome OS. The future is mobile. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543adbb2.3000...@ix.netcom.com
Re: Moderated posts?
On 10/08/2014 09:36 AM, The Wanderer wrote: On 10/08/2014 at 09:18 AM, Steve Litt wrote: On Wed, 8 Oct 2014 12:16:25 +0300 Andrei POPESCU andreimpope...@gmail.com wrote: I was specifically asking about a reference for Thorsten Glaser was ordered not to bring up alternate inits I'll restate the URL I gave in the message to which you responded: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 Read the first 10 messages. I've read through the first 10 (and several more besides), and while I think I see the comments / statements which you are interpreting in that way, it's not completely and unambiguously plain to me that that's what they mean. I think, for clarity on this side of things, that it would be helpful to this particular question if you could provide specific quotes - not just links. (Or No, this must really really be decided first. Moving bug off CC. Please don't re-add it. at the very least, if you could provide links to specific posts, with explanatory comment about how each one fits in to the structure you see.) This might be it, starting with the second message: Why is it so hard to understand that this is (for me) about freedom of choice? It may be, but it's not for the project (and later) No, this must really really be decided first. Moving bug off CC. Please don't re-add it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543b0aac.6080...@ix.netcom.com
Re: implicit linkage
On 10/11/2014 08:18 AM, Andrei POPESCU wrote: Is systemd (the project) trying to do too much? Possibly. Would it be better if this was done in a modular design *done right*? Probably. Yet, none of the solutions so far has *really* caught on. daemontools, runit, s6, init-ng, etc. and even upstart were either never adopted on a large scale or eventually abandoned in favor of systemd. They also probably did not have dependency bundling and an $11B corporation behind them either. :) As far as I understand Linus Torvalds himself admits that a modular kernel design is better, yet he choose to make Linux monolithic. On the other hand Hurd is still not even in a releasable state. I don't think there's any question that modular is harder. It requires actual engineering, not systemd-style hacking. Even Windows experimented with a microkernel in the Cutler days, but ultimately seems to have settled back into bloatware, the path of least resistance. I also wonder if Linux has scaling issues, and how much corporate influence this causes and how much longer Linus can fend it off? Could it be that a modular design for such complex tasks becomes too difficult to *do it right*? I don't know, but I think given its history, the burden of proof is on monolithic, not modular design. A better question may be whether a distributed volunteer project can do real system architecture? (Where is CERN when you need them?) Is systemd going to change the GNU/Linux ecosystem? Definitely. Will this change be good or bad? Only time will tell, but I'm quite sure that even if the change will turn out to be bad it will *not* destroy GNU/Linux, but help it evolve in better ways. If nothing else it gives us a new low bar, a bogyman to replace Windows, which is seeing hard times, and now even resorts to copying Linux. :) Kind regards, Andrei -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54395891.2040...@ix.netcom.com
Re: question about systemd
On 10/09/2014 04:45 AM, Joe wrote: And I have an old laptop and a virtual installation on a Windows laptop, both on sysvinit. But both exist for a small set of purposes, and have nothing like the range of software on my workstation, so I don't know what they tell us. They also only get upgraded occasionally, so they may already be dead computers walking... I think the real issue is that nobody likes maintaining sysvinit scripts. It's quite right that the job of running a piece of software should be the responsibility of the upstream software writers, not the distribution package maintainer, but the very existence of nasty complicated sysvinit scripts surely means that systemd must somehow accomplish the same things. If some of the complications of the init script could be pushed back into the application code, I'd have thought that would have been done long ago. Conversely, if a few systemd functions can replace the init script, then surely the script was over-complicated to start with. And if the widespread use of systemd elsewhere means that upstream writers *have* to take on much of the job that an init script used to do, the init script could be greatly simplified, in some cases to a generic one. I don't think it was ever about init scripts, or init anything. It's political and always has been. If unsupported packages and unmaintained scripts aid purposeful vendor lock-in, then Debian maintainers are part of the problem. I hope that's not the case. I use an old firewall program, guarddog, that survived two release cycles and is still in Debian ports, after losing upstream development. I still run it with Squeeze libs and it works fine. People in Debian with a winners vs losers mindset seem to be promoting an agenda. That would be a sad day for Debian. All the energy arguing or forking Debian could be used to provide solutions and preserve choice for all users. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54367e29.2020...@ix.netcom.com
Re: Data from a serial port
On 10/05/2014 03:50 PM, Ethan Rosenberg wrote: root@meow:/home/ethan# chown ethan /dev/ttyS0 root@meow:/home/ethan# ls -l /dev/ttyS0 crw-rw 1 ethan dialout 4, 64 Oct 4 23:00 /dev/ttyS0 root@meow:/home/ethan# $cat /dev/ttyS0|tee -a scale.txt bash: /dev/ttyS0: Permission denied # adduser ethan dialout then log out and log back in -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54320022.2040...@ix.netcom.com
Re: Debian policy on alternate init systems
On 09/28/2014 08:20 PM, Marty wrote: On 09/28/2014 09:25 AM, Cindy-Sue Causey wrote: As a disclaimer, the easy path to continued across board interoperability may have been successfully addressed in a Debian-User email that is simply waiting its turn to be read.. I'm saving it for my next message :) I was just bored when I wrote that, but it's finally time to act. Thankfully the problem is its own solution, and we can end the debate. Problem: If haters remove systemd, it politely cleans up after itself by removing most of their packages, but we have no equivalent solution. We need a better test for interoperability. My systemd cleanup tool provides consistency and metrics for a systemd-ready package standard. A popup dialog gives ample time to correct a violation, before package quarantine, removal and optional replacement. User choice is respected. So what about packages in transition to full compliance? We just make the cleanup tool a hard dependency, a line in the sand for upstreams. To protect the software chain of trust, background checking and cleanup will soon be mandatory, but it will keep users' best interests in mind. For added convenience a friendly applet shows your compliance status. The sad face gnome means trouble ahead, a happy face means all is well. I wanted to call it systemd-rulez but they said any connection to systemd would provoke the conspiracy nuts. Possible names include: gnome-ossify (descriptive) d-mobilize (inspiring) d-nukem (bold) d-boss (short and to the point) Let me know which name you prefer. We have until the Jessie freeze to decide. Welcome to your compatible, interoperable systemd future. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542d410c.3020...@ix.netcom.com
Re: Debian policy on alternate init systems
On 09/28/2014 09:25 AM, Cindy-Sue Causey wrote: How'd you ever find that in among every single other thing else that's out there to study regarding anything Debian...? Lucky google search I guess. S Genuine question, not trying to make any point in case it comes across that way. I truly do not know. Does that occur now, meaning is that must support being fulfilled? I think the main concern is about future script maintenance, but I'm not in a position to answer that. As a disclaimer, the easy path to continued across board interoperability may have been successfully addressed in a Debian-User email that is simply waiting its turn to be read.. I'm saving it for my next message :) In the meantime this popped up on the google: http://www.itwire.com/opinion-and-analysis/open-sauce/65478-from-next-release-onwards-debian-is-tied-to-systemd It is notable that there is no language stating that it is mandatory to continue to support multiple init systems in Jessie. The committee only expects maintainers to continue to support other init systems. There is no compulsion, no hard-and-fast rule. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5428a5e6.4010...@ix.netcom.com
Debian policy on alternate init systems
The Debian Policy Manual currently supports alternate init systems, and mentions upstart as an example. sysvinit scripts will continue to be required per policy. I got the opposite impression from the TC debate, where part of the justification (IIRC) for systemd was avoiding sysvinit maintenance. Since the policy remains, that argument did not prevail, even if their choice did, if I'm reading this correctly. The relevant policies are 1.1: Packages that do not conform to the guidelines denoted by must (or required) will generally not be considered acceptable for the Debian distribution. and 9.11: any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script ... https://www.debian.org/doc/debian-policy/ch-opersys.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54275155.1090...@ix.netcom.com
Re: systemd bug closed - next steps?
On 09/24/2014 02:45 PM, Brian wrote: Chanting Red Hat Conspirancy to yourself before falling into a deep slumber is one thing. Convincing most other people it exists is a task which requires a little bit more. FUD alert Let's see, the real goal of systemd has nothing to do with init or service management, but with IPC standardization, sandboxing apps and TC/DRM support, enabling an internet app store for Linux distros. That requires a PID 1 kitchen sink service to drive its dependency chains deeply into userspace using at least 40 APIs. Then just call it an init system and anyone opposing a luddite, manufacture a crisis by killing services it replaces and threaten the whole application stack. By then everyone has compared it with the old init, a perfect foil. While everyone is arguing about init systems, nobody will notice your original goal, but if they do just call it a paranoid conspiracy theory. sigh you're right, too unbelievable. Back to Hanlon's razor. :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54238718.7070...@ix.netcom.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 09/23/2014 05:14 AM, Martin Steigerwald wrote: So my challenge is to you: *Act* for change. Instead of just venting your frustration here, which will do nothing, absolutely and utterly nothing for any change! But basically the opposite, the more energy you put into venting engaging here in a ton of threads, the less energy you will have to bring forth change. I bet most of those here, who criticize systemd never ever have even *tried* to take any of this upstream. I am delighted to see any proof of that you did. Just really important: Watch your tone. If you are disrepectful, then chances are that you will be ignored. And IMHO *rightfully* so. Ciao, My take is that this is not a problem with upstreams, including systemd. It's useless to bother upstreams with Debian's internal issues, which are centered around a growing dependency on Red Hat's one-size-fits-all business model, which could be a poison pill that kills Debian as collateral damage. In that sense maybe you could call it an upstream issue, but it's one that I suspect is particularly impervious to downstream feedback (except maybe from RHT shareholders). The only realistic user option for the majority is to stop using. That exodus, as far as I can tell, has already started with the most technical users. They are glad to use hobby project software but don't have time to referee internet squabbles. Their main interest now will be to gauge risk going forward or just post out of curiosity to ask WTF is happening to Debian? From my perspective the most important users in the server space and the mobile/embedded ARM space tend to think this not going well for Debian which was the underdog to begin with, but systemd is a big setback and will cause it to be dropped like a hot potato. I only have a small window to see through but have been watching closely for years. I am always looking for alternate options on this. Debian use can make a difference, by exercising choice. For Debian users to make a difference, Debian has to fix Debian. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54215824.9020...@ix.netcom.com
Re: systemd bug closed - next steps?
On 09/23/2014 12:11 PM, Andrei POPESCU wrote: On Lu, 22 sep 14, 21:17:28, Marty wrote: 1) The goal is modular Debian. Multi-init is the means to achieve it. Being tied to one init system is what caused Debian’s problems, and the replacement did not fix it. A modular system has to support all init systems, including systemd, clones and custom inits. While you're at it how about also making sure we can have a dietlibc or uClibc version of Debian? After all, depending on glibc is also not very good. Oh, and don't forget about udev and X.Org. There is already work in progress trying to compile Debian with something other than GCC, so you don't need to worry about that. Yes this is a joke, but only in part. It's very interesting how suddenly people are so worried about Debian being tied to one piece of software, while this has been happening all along. Kind regards, Andrei I don't think the problem is being tied to software, as much as the software one is being tied to, and the person(s) doing the tying. Anyway I intentionally did not propose to solve all the world's problems. That comes later. For now it's just a tiny bite-sized project well within the charter, that would at least suggest that adults are still in control. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54221a2f.3010...@ix.netcom.com
Re: systemd bug closed - next steps?
On 09/22/2014 05:39 AM, berenger.mo...@neutralite.org wrote: Le 22.09.2014 01:51, John Hasler a écrit : Martin Read writes: consolekit is indeed the thing that systemd-logind replaces (and systemd-logind was the reason the maintainers of consolekit stopped maintaining it). So who is going to step forward and start maintaining it? Nobody needs to. systemd-login does *not* depends on the init system. At no levels. So why should someone have to maintain an alternative? (well, there are probably tons of reasons, indeed, but systemd-login being a part of systemd is not a correct one since login part does not depends on init part.) So Debian won't do it, or maybe Red Hat. Not sure whose calling the shots here. Nobody wants it, at least nobody who counts. It's not the business plan. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54201244.8010...@ix.netcom.com
Re: systemd bug closed - next steps?
On 09/22/2014 05:07 AM, Jonathan Dowland wrote: Hi Rob, I saw the bug closed (via mail on -devel) and personally thought it shouldn't have been. However when considering next steps my advice would be to leave bugs alone for a short while and let things cool off. It's important and useful to file bugs, but that in and of itself doesn't solve problems - they just track problems. My advice, if you have spare time to spend on trying to get this problem solved, would be to think beyond the bug filing, and try to figure out which packages need to be modified in order to solve the problem. First you have to know what the design goals are. Without that, there can be no agreement on what packages have to be modified. I don't think anything less than multi-init support would be worth pursuing at this point. There are a number of well-know arguments for and against it so I won't repeat them. This is just a list of steps I think it will take to accomplish it: 1) The goal is modular Debian. Multi-init is the means to achieve it. Being tied to one init system is what caused Debian’s problems, and the replacement did not fix it. A modular system has to support all init systems, including systemd, clones and custom inits. 2) All init systems, to support multi-init, will probably have to support sysvinit as a backwards compatibility option, and systemd unit/service files or a translator for future compatibility. 3) All services obsoleted by systemd (like login) must be supported at least until they can be upgraded or replaced. They may have to support some systemd features for compatibility reasons. 4) To have the slightest chance of succeeding, I think modular Debian packages will have to go into unstable soon and be in the next testing cycle. Time is against it and it be too late already. 5) It would be a massive project, but the individual tasks are small and modular. I think it could succeed with sufficient buy-in. Even systemd proponents can see the value of modular Debian, and will accept the challenge of maintaining a universal operating system. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5420ca28.7010...@ix.netcom.com
Re: Effectively criticizing decisions you disagree with in Debian
On 09/21/2014 01:12 AM, Don Armstrong wrote: On Sat, 20 Sep 2014, Jerry Stuckle wrote: Then please explain to us why, with all of the negative technical aspects surrounding systemd, it looks to be the default init in Jessie. You can start by reading why I voted for systemd: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3661 My summary of key points (about the discussion, not you personally): 1) The bug report leading to the decision is about dependencies / conflicts. (The fix is to add even more dependencies and conflicts.) 2) Why the rush? Pressure from upstream. (Decision by hostage taking. One init, or the Gnome gets it.) 3) We can't agree (so give them what they want). 4) We all like user choice (too bad we can't have it). 5) A technical committee decides an issue with vast non-technical implications. (What could possibly go wrong?) 6) There is no plan to address vendor lock-in and dependencies which caused the bug. Even a warning proposal fails. Looking in from the outside, the whole process seems incredibly myopic. The likely effect (already beginning) will be significant upgrade churn and backwards incompatibility, without commensurate benefits. The reward for those efforts will be additional gratuitous dependencies, fewer options, less control and less freedom. The kernel has Linus to defend it. We have this sham, along with the unwanted Red Hat bundleware with more to follow. The empty promise of user choice was a smokescreen. Debian speak with forked tongue. What I don't understand is that criticism and other forms of speaking up cannot be considered as a form of contribution. Constructive criticism is often a useful contribution. Destructive criticism, much less so. Disagree all you want, but don't malign others when you do so. (Or at least, don't do it on Debian communication infrastructure.) The time to consider the effect on volunteers was when you were making the decision. The time to consider the effect on future devs, who might be interested in fixing this, is now. It's unclear that Debian even admits the problem exists, much less that it is willing to address it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541f4052.7050...@ix.netcom.com
Re: Jessie and Systemd integration
On 09/19/2014 07:34 PM, Joel Rees wrote: On Sat, Sep 20, 2014 at 1:36 AM, T.J. Duchene t.j.duch...@gmail.com wrote: I do not understand something that has been bugging me for a while and I'd like to ask the many minds of the list why this would not be possible, especially since Debian has some of the best Linux people out there, who have worked on the system for 20+ years. Why is it not possible to create a completely generic shell script - basically ala SysV that can parse systemd config files for those use cases where Systemd is undesirable? Shell scripts can parse simple configuration files, in part because simple configuration files tend to either directly use the shell syntax (a custom the systemd crew explicitly eschews) or have a form that can be massaged, via awk, sed, or m4 scripts into shell syntax. (Somewhat simplifying things here.) Systemd config files are not simple. How about giving the parsing job to init? I hear it will soon be out of a job and looking for work. It violates the do one thing idea but for a good cause, I think. You could start here: https://github.com/intgr/systemd/blob/master/src/shared/conf-parser.c A parser lib could be used by other system packages, like cggroups. It's not exactly what the OP proposed, but I don't see any problem with the basic idea. That would not prevent using lex/yacc to define a parser and writing our own parser in C, but, the configuration files are a relatively minor part of the problems with systemd. systemd was billed as an init replacement, and sysvinit script maintenance was cited as a reason for the change, so there's that. What systemd does is basically a generic process of reading parameters from a file and using them to start a service. If that were true, I don't think anyone would be fussing about systemd at all. That is, if systemd were just a generic service starter, it would be keeping its fingers out of login, file permissions, and all sorts of other stuff that it gets itself entangled with. Like kbd and ntp, and more to come, I'm sure. As far as can tell, configuration is the only thing that (weakly) ties them to systemd. It would be properly delegating, as the pid 1 process must, if you want to keep a system stable and secure in the long term. I am not a systemd expert but supporting the systemd configuration format does not preclude a minimal init, as far as I can tell. Granted, this approach would have the benefits that systemd has, but the concerns about systemd being too opaque or monolithic could be almost mitigated. If your assumptions were correct, mitigation would be meaningless. systemd would be small and simple enough that monolithic and opaque would not be terms that would apply. The remaining concerns such as login and so on can be addressed separately. Those remaining concerns are where the bulk of the problems lie. Having a systemd parser could give the threatened utilities more reason to be maintained. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541dd508.6090...@ix.netcom.com
Re: preseeding: disable systemd
On 09/14/2014 08:15 AM, The Wanderer wrote: The fourth would require clarification from you as to exactly what it is you do require. (not OP but) I require the exclusion all packages by their dev teams from my computer. Is that clear enough? Linus doesn't trust them. Why should I? Wherever their tentacles reach, they should be eradicated. default init was supposed to imply choice, now we learn it was just lip service and the new init is the borg collective. How are people supposed to respond? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541636ed.4090...@ix.netcom.com
Re: Unable to get X to start on new flat screen monitor using DVI
(II) VESA(0): VESA VBE DDC read failed Are you missing an I2C driver? Also, just WAG but maybe 1280X720 will work anyway. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fdfc1ab.9000...@ix.netcom.com
Re: Mythtv problem with versions
On 04/29/12 10:41, Rob Owens wrote: On Tue, Apr 17, 2012 at 07:24:07PM +0100, Alan Chandler wrote: I have a server running Squeeze. It has mythtv-backend to record all my TV programs. On my desktop I run Sid. After an update over the weekend, my Mythtv Frontend will no longer connect to my backend, complaining that This version of MythTV requires an updated database. (schema is 35 versions behind) Please run mythtv-setup or mythbackend to update your database. I suspect that I need to somehow update the backend. But with that being Squeeze, that could be rather difficult. Anyone got any suggestions of how to deal wth this. [Mythweb will stream the TV. and that almost works, but I do tend to want to save programs mid way through or want to rapidly skip forward and backward. The media play that is launched by the browser doesn't seem to all any of this.] I confirmed with the debian-multimedia maintainer that the testing version of MythTV would always be compatible with the stable version. I am running a stable backend, and a testing frontend. My testing mythtv-frontend is at version 0.25. I get the same error message as the original poster. Reportedly, the 0.24/0.25 combination does not work: http://www.mythtv.org/pipermail/mythtv-users/2012-April/332832.html If you got this combination to work then I would like to know how you did it. I don't think that the unstable version is necessarily compatible with the stable version. In fact, I recall recently on the debian-multimedia mailing list that there was a new version in unstable. So I suspect what happened is that your frontend got updated, and it refused to communicate with your stable backend, because the databases have different schemas. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fba5466.8010...@ix.netcom.com
no recent Squeeze updates
I have not gotten any package updates, including security upgrades, in any of my Squeeze systems for at least two weeks. In my experience this is unprecedented. I have not changed my apt config or sources.list. Is there a change in the update policy? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2b23b2.8080...@ix.netcom.com
Re: Ma Lenny supporte 4Gb de Ram en 32bits
En fait cela s'explique surtout par windows XP qui est con (enfin on peux toujours ajouter un truc du genre /PAE dans le boot de windows). Leopard qui n'était pas du tout 64 bits supportais très bien plus de 3Go en fait cela dépends en grande partie de l'os et de sa gestion de la mémoire paginée étendue. Sans Prendre trop de risque je dirais que les machine qui aujourd'hui ont plus de 3 Go n'ont pas de problème matériel pour gérer ça. Cela dis la mémoire paginée étendu a ses limites (en taille maxi) et le 64 bits permet de largement aller plus haut. Au plaisir _Marty_ Le 8 oct. 2010 à 12:24, Frédéric Massot a écrit : Le 08/10/2010 10:57, Le Cerdocyon a écrit : Bonjour, J'ai un portable perso à la maison ou j'ai Windows Xp pour moi et ma femme + une lenny en multiboot au cas ou. Ce matin, je décide de booter sur la lenny du portable (ca fait bien 2 mois que je n'y étais pas allé) et là je trouve que les applis se chargent vite. (Je sais qu'à l'époque ou je me suis renseigné un peu sur le support du 32 bit/4Gb de ram il fallait vraissemblablement utiliser le support Bigmem, ce que j'avais fait et installé, sans pour autant avoir mes 4GB qui s'affichait avec la commande free et un cat /proc/meminfo non plus). Donc les applis se charge vite, je décide de regarder du coté de free, ? j'ai mes 4Gb de ram un cat /proc/meminfo Pareil ! Je me dis super, mais comment ça se fait ? Je vous pose donc la question, car figurez-vous qu'au boulot j'ai une bonne bécane pour bosser, et j'ai la meme config kernel que sur le portable perso, et je n'ai que 3GB de reconnu. Ça dépend du BIOS et/ou du chipset, certain ne sont pas capable d'adresser les 4 Go. Plus le problème du PCI hole : http://en.wikipedia.org/wiki/PCI_hole Il y a quelques années sur un serveur Debian 32 bits avec plusieurs instances Zope (ça bouffe de la RAM) j'avais essayé d'aller jusqu'au 4 Go. Avec ou sans le mode PAE j'avais de gros ralentissement. Le mieux que j'ai pu faire c'est sans le mode PAE et en limitant le kernel à 3.7 Go de RAM (j'ai tester plusieurs valeurs). Bref, ça dépend de ton matériel. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | ===Debian=GNU/Linux=== -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4caef143.2090...@juliana-multimedia.com -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp176a95ff5a08bc51589002ff4...@phx.gbl
[apt-get] Problème d'installation.
Bonjour à tous, J'ai quelques problèmes avec l'installation d'un package que j'ai créé. Je l'installe, mais la machine ne semble pas s'en 'souvenir'. Je m'explique : Je n'ai aucun soucis pour le créer, je pense donc (à tord peut être) que tout ce qui est nécessaire est présent dans le package. Lorsque je fais un apt-get install, le package s'installe parfaitement, tout fonctionne comme je le veux. Lorsque je fais un apt-get remove, le package est completement supprimé. Jusqu'ici pas de soucis. Mon problème vient lors d'une mise à jour. Bien qu'une nouvelle version se trouve sur mon dépot, apt-get ne semble pas vouloir le mettre à jour -le paquet n'apparait pas dans la liste de ceux qui vont être mis à jour...- J'ai alors vérifié la priorité de mon package : je fais un apt-cache policy sur mon package, juste apres l'avoir installé -via apt-get install, puis vérification que tout fonctionne correctement-. Il me répond alors qu'aucune version n'est installée actuellement. Le problème pourrait il venir du fait que j'installe le package sur une machine Ubuntu -je sais, mais j'ai pas le choix- même si les packages y fonctionnent de la même manière ? Il s'agit d'un package de configuration, aucun binaire à l'interieur, seulement des fichiers à placer au bon endroit et un script à lancer. Il ne contient donc qu'un seul fichier pour la création du package -le fichier DEBIAN/control- . Cela semble suffire pour la création du package sans erreur -ni warning-. Peut être n'est ce pas suffisant pour l'installation ? Quelqu'un aurait-il déjà connu ce problème ? Si jamais je ne suis pas sur la mailing list adhéquat, pourrait on me réaiguiller ? Merci a tous par avance, Fred -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c3b275d.9020...@enseirb-matmeca.fr
Probleme aptitude upgrade
Bonjour a tous, J'ai recemment créé un dépot de packages de configuration d'ordinateurs. J'ai un soucis au niveau de l'installation des mises a jour. Je m'explique : L'installation des packages se fait sans probleme. C'est quand je veux faire les mises a jour que les soucis arrivent. Aptitude update recupere correctement les fichiers Release/Packages de mon dépot. Quand a la suite je fais un aptitude upgrade, aucun de mes paquets n'est mis a jour. Pourtant leurs versions sont bien anterieures a celles se trouvant sur le dépot. Pour être precis, aptitude upgrade ne cite nul part mes packages, meme pas dans les packages qui ne vont pas etre mis a jour. Si je passe par la version graphique d'aptitude, il m'est bien dit que mes packages ont une nouvelle version disponible sans pour autant les installer directement. Je suis donc un peu perplexe face a cela... Si quelqu'un a une idée sur l'origine de ce probleme, Merci par avance, Frederic -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c3474d4.6050...@weblib.eu
Re: script bash
Tahar BEN ACHOUR wrote: Bonjour à tous, Bonjour, Une petite question en bash, Je voudrais savoir comment faire pour échapper les ' ' afin que ma variable soit prise en compte, [..] sed -i '1iLogFile /srv/logs/$domain' $line ici je n'ai pas su comment echapper la quote pour que $domain soit prise en compte dans sed -i 1iLogFile /srv/logs/$domain' $line Je fais ca en mettant ma variable entre double quote : sed -i '1iLogFile /srv/logs/$domain' $line Attention, mes commandes sed sont souvent elles aussi entre double quote (sed commande fichier), je ne sais pas si cela influe ou non. Fred -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c3483a4.9090...@enseirb-matmeca.fr
Re: Re : script bash
Tahar BEN ACHOUR wrote: Je fais ca en mettant ma variable entre double quote : sed -i '1iLogFile /srv/logs/$domain' $line Merci pour ton aide, mais ça ne marche pas ainsi j'obtiens $domain comme résultat Et en mettant des double quote partout : sed -i 1iLogFile /srv/logs/$domain $line ? Fred Attention, mes commandes sed sont souvent elles aussi entre double quote (sed commande fichier), je ne sais pas si cela influe ou non. Fred merci -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c3487d4.3070...@enseirb-matmeca.fr
Re: Probleme aptitude upgrade
Regarde ce que te sort un apt-cache policy La priorité pour mon dépot est de 500, comme les autres. et un apt-cache policy nom du package Ici, je vois comme un soucis en effet : WeblibBase : Install : (aucun) Candidat : 1.0.4.0 C'est étrange puisque je viens juste d'installer la version 1.0.4.0 ... Est il possible qu'apt ne se 'souvienne' pas d'avoir installer un package ? Sachant que je suis le developpeur du package, j'ai pu faire une erreur dans la creation des fichiers importants, malgré les tuto suivis ... Fred Il se peut que ton dépôt n'ait pas la bonne priorité. Il faut régler ça dans le fichier /etc/apt/preferences. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c348a86.1040...@enseirb-matmeca.fr
aptitude install et ssh
Bonjour a tous, Je voudrais monter un depot de package sur lequel les utilisateurs viendrait se servir via ssh. Pour cela je vais creer un user qui sera utiliser pour recuperer les packages de maniere standard, avec un aptitude/apt-get install. Je voudrais donc limiter au maximum les droits de ce user pour des raison de sécurité. Je cherche donc a savoir quelles sont les commandes executées sur le dépot lors d'un aptitude install. J'ai tenté de regarder le code source, mais mes connaissances en C++ sont limitées. Si quelqu'un a la réponse, ou peut me conseiller un endroit ou chercher, je suis preneur. Merci d'avance, Fred PS : dans le cas ou je ne suis pas du tout au bon endroit, je prend aussi un reaiguillage :) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4bfe4a93.5000...@enseirb-matmeca.fr
Re: [HS] droits d'accès au /home
La question ne se pose plus trop maintenant que les clés usb / petit disque durs sont largement utilisé, selon moi, les données perso pures n'ont rien a faire que se soit sur le poste et encore moins sur le serveur (je parle pas de wallpaper ou autre accessoirisation du desktop). Quand aux données pro, je trouve que le patron et l'admin ont tout a fait droit de fouiller si besoin (récupérer un document important alors que l'employé est absent etc...). Rémi Le 19 mars 2010 à 13:29, Jean-Yves F. Barbier a écrit : Julien a écrit : Une petite question HS, je voudrais savoir quel est le statut dans l'entreprise des 'répertoire personnel' des employés. Qui a le droits d'y accéder et sous quels conditions ? Est-ce que l'administrateur peux aller fouiller dans les 'home', est-ce que le patron peux y accéder parce que c'est le patron ? C'est plutôt complexe et c'est un droit qui s'appuie plus sur des jurisprudences que sur des textes. Pour faire court, disons qu'en général et dans la limite du raisonnable, tu as le droit de stocker des données persos, à condition qu'elles soient bien identifiées (le dir personnel). Mais dans tous les cas le règlement intérieur de l'entreprise prévaut (à condition, bien sur, que tu l'ai signé/accepté); il n'y-a, à ma connaissance, pas de jurisprudence sur le stockage; par contre il-y-a en a sur les emails persos qui ont été reconnus... persos (mais rien ne s'oppose à ce que la société rejette tout email non-pro au niveau de son SMTP: c'est son matos, c'est juste la prise de connaissance du contenu de l'email qui est interdite.) Au vu des récents édits royaux (oops! lapsus: lois liberticides), il est vraisemblable que si tu te fait gauler à stocker des fichiers sous copyright sans en avoir la license, tu sois passible d'un licenciement pour faute grâve. Dans les faits, personne ne dit rien quand on stocke qq photos des mômes ou 2-3 fichiers de tableur/trt; au-delà, c'est s'exposer soit à la vigilance de l'admin soit à celle de softs conçus pour. Et dans *tous* les cas, on peut tout à fait t'opposer que ton dir /home étant sauvegardé toutes les NN heures, tu fais grossir inutilement les backups; et donc t'interdire tout doc perso sur le matériel de l'entreprise (OU les supprimer d'autorité, sans te consulter, et ceci de plein droit.) -- Reality is a cop-out for people who can't handle drugs. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4ba36e12.3040...@gmail.com -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp588a88117a2714c3a7c8a1cc...@phx.gbl
Re: Probleme avec la commande dpkg-scanpackages
Lors de l'exécution de la commande dpkg-scanpackages pour créer le fichier Packages.gz, j'ai une erreur : dpkg-scanpackages . /dev/null | gzip -9c Packages.gz Est-ce que LANG=C dpkg-scanpackages . /dev/null | gzip -9c Packages.gz fonctionne ? J'obtiens toujours le même message d'erreur, mais en anglais cette fois :) dpkg-scanpackages: error: Unprocessed text from ./monpackage.deb control file; info: Quelle version de dpkg-dev avez-vous sur ce système ? dpkg-scanpackages --version Debian dpkg-scanpackages version 1.15.4ubuntu1. Il semblerait que ce soit la version à jour. Cordialement, Frederic -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b9771df.9000...@enseirb-matmeca.fr
Re: Probleme avec la commande dpkg-scanpackages
Raphael Hertzog wrote: Bonjour, On Wed, 10 Mar 2010, MARTY wrote: Lors de l'exécution de la commande dpkg-scanpackages pour créer le fichier Packages.gz, j'ai une erreur : dpkg-scanpackages . /dev/null | gzip -9c Packages.gz Est-ce que LANG=C dpkg-scanpackages . /dev/null | gzip -9c Packages.gz fonctionne ? J'obtiens toujours le même message d'erreur, mais en anglais cette fois :) dpkg-scanpackages: error: Unprocessed text from ./monpackage.deb control file; info: Et que donne dpkg-deb -I ./monpackage.deb control ? Avec cette commande, j'ai le contenu de mon fichier control qui est affiché en totalité : ma...@marty:~/depotWebLib/bras$ dpkg-deb -I ./monpackage-1.deb control Package : monpackage Version : 1 Section: base Priority: optional Architecture: all Depends: Maintainer: Weblib Description: blabla Et puis merci de coller le message d'erreur en entier, normalement il est de cette forme (en anglais): Unprocessed text from %s control file; info:\n%s / %s Or je n'ai pas vu le / dans votre copier/coller du message d'erreur. En effet, j'ai pas mégarde tronquer le message d'erreur à sa première ligne. Le voici en globalité : ma...@marty:~/depotWebLib/bras$ LANG=C dpkg-scanpackages . /dev/null | gzip -9c Packages.gz dpkg-scanpackages: error: Unprocessed text from ./monpackage-1.deb control file; info: Package : monpackage Version : 1 Section: base Priority: optional Architecture: all Depends: Maintainer: Weblib Description: blabla / Package : monpackage Version : 1 Section: base Priority: optional Architecture: all Depends: Maintainer: Weblib Description: blabla Il s'agit exactement de la même erreur que pour la commande dpkg-scanpackages . /dev/null | gzip -9c Packages.gz, mais en anglais. Cordialement, Frédéric -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b978487.4060...@enseirb-matmeca.fr
Re: Probleme avec la commande dpkg-scanpackages
Il ne doit pas y avoir d'espace avant les :. Je ne sais pas comment vous avez généré ce paquet, mais ces espaces ne doivent pas y être, c'est à cause de cela que ces informations ne sont pas reconnues par dpkg-scanpackages. A+ Merci beaucoup pour ce coup de main, j'ai honte de mon erreur ... Comme quoi, ce n'est pas parce que le fichier .deb est créé que le control est valide. Je tacherai d'etre plus attentif a l'avenir :-) Frederic -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b979b65.4040...@enseirb-matmeca.fr
Probleme avec la commande dpkg-scanpackages
Bonjour à tous, Après avoir créer un package perso, j'essai de le monter sur un dépot sur ma machine. Lors de l'exécution de la commande dpkg-scanpackages pour créer le fichier Packages.gz, j'ai une erreur : dpkg-scanpackages . /dev/null | gzip -9c Packages.gz dpkg-scanpackages: erreur: Texte non traité du fichier de contrôle ./monpackage-0.1.deb ; info : Package: monpackage Version : 0.1 Section: main Priority: optional Architecture: all Depends: Maintainer: sirmav Description: bla Lors de la construction du package, je n'ai pas de problème avec le fichier DEBIAN/control. J'ai beau essayé de changer quelques lignes dans le fichier control, soit cela ne change rien au problème de base, soit c'est au niveau de la création du .deb que cela coince. Quelqu'un aurait il déjà eu ce problème, ou une idée de solution ? Merci par avance, Frédéric -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b96428c.3080...@enseirb-matmeca.fr
Re: CD Debian personnalisé avec mon propre Kern el
Salut, J'ai eu le meme genre de probleme, tu pourrais peut-etre utilisé un .deb classique qui contiendrait ton kernel.deb et le placerait dans /root (par exemple) + dans ton profile.postscript rajouter un dpkg -i /root/kernel.deb Cordialement, Rémi Le 2 mars 2010 à 14:53, Hugo Deprez a écrit : Bonjour, Merci pour l'information ! J'ai donc étudié live-helper. J'ai généré une image avec les commandes suivantes : lh_config -b iso -a amd64 --mirror-chroot http://ftp.fr.debian.org/debian/ --debian-installer netinst j'ai copié mon kernel personnalisé dans config/chroot_local-packages/ j'ai tapé la commande suivante : LH_LINUX_PACKAGES= J'ai testé mon ISO, sur le prompt j'ai fais install. Mais il ma installé un kernel 2.6.26-2-amd64... Lors de la génération de l'iso il me semble pourtant avoir vu mon package kernel être configuré. Une idée? Hugo 2010/3/2 Jean-Bernard Yata yata...@revolsys.fr Hugo Deprez wrote: Bonjour, je souhaiterais créer un CD d'installation Debian personnalisé. Je me suis documenté sur simple-cdd qui semble correspondre à mes besoins. Cependant je voudrais que le CD installe un kernel fait maison (j'ai généré un .deb). Je n'ai pas trouvé la méthode pour faire cette modification. Quelqu'un a une idée ? Merci, Hugo Bonjour Hugo, Regarde du coté de live-helper. Ce te permet entre autres de générer des images usb et cdrom de distribution debian, le tout tres customisable. JB -- Best regards, -- Jean-Bernard Yata System Engineer Debian France Mirror Maintainer : debian.revolsys.fr -- Linux Debian User Group Community : IRC : irc.debian-mirror.com/#linux WWW : http://www.debian-mirror.com
Re: CD Debian personnalisé avec mon propre Kern el
Et bien tu le mets a coté de ton fichier preseed et package avec une sytaxe de script shell, au fait oublie pas de rm ton .deb de /root, c'est plus propre c'est un des 4 fichier de profile (avec .udeb aussi) Le 2 mars 2010 à 15:51, Hugo Deprez a écrit : Jean-bernard, j'ai crée dans le dossier que tu m'as indiqué un dossier boot où j'ai copié les fichiers : config-2.6.32-xx initrd.img-2.6.32-xx vmlinuz-2.6.32-xx et crée un dossier grub/menu.lst j'ai recrée mon ISO, booter dessus en tapant install, mais rien n'y fait il m'a encore installé un 2.6.26-2 Pour Rémi : pourquoi pas, mais quel est la syntaxe du fichier profile.postscript ? Il doit se trouver à la racine de mon espace de travail (dans le dossier config)? Merci 2010/3/2 Rémi Marty bham1...@hotmail.com Salut, J'ai eu le meme genre de probleme, tu pourrais peut-etre utilisé un .deb classique qui contiendrait ton kernel.deb et le placerait dans /root (par exemple) + dans ton profile.postscript rajouter un dpkg -i /root/kernel.deb Cordialement, Rémi Le 2 mars 2010 à 14:53, Hugo Deprez a écrit : Bonjour, Merci pour l'information ! J'ai donc étudié live-helper. J'ai généré une image avec les commandes suivantes : lh_config -b iso -a amd64 --mirror-chroot http://ftp.fr.debian.org/debian/ --debian-installer netinst j'ai copié mon kernel personnalisé dans config/chroot_local-packages/ j'ai tapé la commande suivante : LH_LINUX_PACKAGES= J'ai testé mon ISO, sur le prompt j'ai fais install. Mais il ma installé un kernel 2.6.26-2-amd64... Lors de la génération de l'iso il me semble pourtant avoir vu mon package kernel être configuré. Une idée? Hugo 2010/3/2 Jean-Bernard Yata yata...@revolsys.fr Hugo Deprez wrote: Bonjour, je souhaiterais créer un CD d'installation Debian personnalisé. Je me suis documenté sur simple-cdd qui semble correspondre à mes besoins. Cependant je voudrais que le CD installe un kernel fait maison (j'ai généré un .deb). Je n'ai pas trouvé la méthode pour faire cette modification. Quelqu'un a une idée ? Merci, Hugo Bonjour Hugo, Regarde du coté de live-helper. Ce te permet entre autres de générer des images usb et cdrom de distribution debian, le tout tres customisable. JB -- Best regards, -- Jean-Bernard Yata System Engineer Debian France Mirror Maintainer : debian.revolsys.fr -- Linux Debian User Group Community : IRC : irc.debian-mirror.com/#linux WWW : http://www.debian-mirror.com
Re: CD Debian personnalisé avec mon propre Kern el
Par contre si tu as une idée pour integrer le fameux firmware bnx2 simplement (sans sortir initgz de l'iso puis lui concatener le microcode contenu dans le deb) je suis preneur ^^ Rémi Le 2 mars 2010 à 15:04, Rémi Marty a écrit : Salut, J'ai eu le meme genre de probleme, tu pourrais peut-etre utilisé un .deb classique qui contiendrait ton kernel.deb et le placerait dans /root (par exemple) + dans ton profile.postscript rajouter un dpkg -i /root/kernel.deb Cordialement, Rémi Le 2 mars 2010 à 14:53, Hugo Deprez a écrit : Bonjour, Merci pour l'information ! J'ai donc étudié live-helper. J'ai généré une image avec les commandes suivantes : lh_config -b iso -a amd64 --mirror-chroot http://ftp.fr.debian.org/debian/ --debian-installer netinst j'ai copié mon kernel personnalisé dans config/chroot_local-packages/ j'ai tapé la commande suivante : LH_LINUX_PACKAGES= J'ai testé mon ISO, sur le prompt j'ai fais install. Mais il ma installé un kernel 2.6.26-2-amd64... Lors de la génération de l'iso il me semble pourtant avoir vu mon package kernel être configuré. Une idée? Hugo 2010/3/2 Jean-Bernard Yata yata...@revolsys.fr Hugo Deprez wrote: Bonjour, je souhaiterais créer un CD d'installation Debian personnalisé. Je me suis documenté sur simple-cdd qui semble correspondre à mes besoins. Cependant je voudrais que le CD installe un kernel fait maison (j'ai généré un .deb). Je n'ai pas trouvé la méthode pour faire cette modification. Quelqu'un a une idée ? Merci, Hugo Bonjour Hugo, Regarde du coté de live-helper. Ce te permet entre autres de générer des images usb et cdrom de distribution debian, le tout tres customisable. JB -- Best regards, -- Jean-Bernard Yata System Engineer Debian France Mirror Maintainer : debian.revolsys.fr -- Linux Debian User Group Community : IRC : irc.debian-mirror.com/#linux WWW : http://www.debian-mirror.com
Mythtv 0.22 segfault
With recent mythtv upgrade 0.22 I get a kernel message mythfrontend[8527]: segfault at 0 ip b4f0af13 sp a9168b48 error 4 in libmpeg2.so.0.0.0[b4f05000+17000] when I try to play back any recording, on my mostly stock Lenny system. (The main differences are upgraded radeonhd drivers, 1.2.5-1 and kernel 2.6.31.5). Everything else in mythtv works, and since mpeg2 crashes I don't think it's the QT4 upgrade issue. Anyone else have problems with 0.22+fixes20100105? I don't see an update in the pipeline but I'm not sure how or whether to escalate. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
SOLVED Re: Gnome URL icon associations
Marty wrote: In my debian Etch system, the default browser is iceape, the link /etc/x-www-browser points to /usr/bin/iceape, and mozilla is the selected default browser using the gnome Desktop-Preferences-Preferred Applications applet. I am not familiar with gconf configuration. Regardless of the default browser settings, desktop icon URLs opened my mouse click on the desltop, or opened within nautilus appear in konqueror. When konqueror is uninstalled, the desktop URL icons are opened by gedit instead. Default browser selection works normally, however, for URL icons placed in a panel. In addition to finding a fix, I am curious about why the system defaults to either konqueror or gedit, and the relevant configuration files and settings. Thanks for any help. I fixed the problem by adding the following lines to ~/.local/share/applications/defaults.list: application/xhtml+xml=iceape.desktop text/html=iceape.desktop text/xml=iceape.desktop This was needed is because the default browser is epiphany in the gconf global defaults.listfile. A more permanent solution may be changing the global defaults, applying them to new users as well, but still I don't know how to safely do that. Since the last posting, in addition to the previous failed attempts, I also tried changing the default gnome browser and URL handlers settings using gconf-editor, which failed, and forcing the KDE MIME setting in kcontrol, which worked around the problem but disabled normal MIME handling. I don't know why it should matter at all in Gnome, but at least in explains why Konqueror was starting. In seeking the fix I found at least four separate and differently working mechanisms related to MIME or file association in debian, not including their local and global versions. Although I have a fix for the immediate problem, I still don't know why there are so many ways in Debian to perform a similar function, how they overlap and differ, where they are all documented, or even which package(s) on which to file a bug or wishlist report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Gnome URL icon associations
In my debian Etch system, the default browser is iceape, the link /etc/x-www-browser points to /usr/bin/iceape, and mozilla is the selected default browser using the gnome Desktop-Preferences-Preferred Applications applet. I am not familiar with gconf configuration. Regardless of the default browser settings, desktop icon URLs opened my mouse click on the desltop, or opened within nautilus appear in konqueror. When konqueror is uninstalled, the desktop URL icons are opened by gedit instead. Default browser selection works normally, however, for URL icons placed in a panel. In addition to finding a fix, I am curious about why the system defaults to either konqueror or gedit, and the relevant configuration files and settings. Thanks for any help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt/dselect anomaly
Daniel Burrows wrote: On Sun, May 18, 2008 at 08:33:35PM -0400, Marty [EMAIL PROTECTED] was heard to say: I usually keep current with the Debian archive using apt-get. Sometimes, however, I install programs using dselect. After upgrading to the latest Debian archive using apt-get update/upgrade, I got the following message while running dselect: The following packages will be upgraded: openssh-client openssh-server It happened on two different similarly configured machines. I'm pretty sure this has never happened to me before. I have always thought that upgrading using either apt-get or dselect (using the apt method) were equivalent, at least with respect to staying current with the archive. Am I missing something major? Thanks for any illumination. The latest version of openssh-server depends on openssh-blacklist due to the security problems with openssl that came up recently. If you only use apt-get upgrade, openssh-server won't get upgraded because upgrade refuses to install new packages. Did openssh-blacklist get installed too when you used dselect? Yes. I had missed the warning about the kept back packages. Thanks. I have repeated the upgrade with another machine to confirm this explanation: apt-get update/upgrade outputs in part: The following packages have been kept back: openssh-client openssh-server The following packages will be upgraded: libssl0.9.8 linux-source-2.6.18 openssl rdesktop ssh dselect outputs in part: The following NEW packages will be installed: openssh-blacklist The following packages will be upgraded: openssh-client openssh-server 2 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
apt/dselect anomaly
I usually keep current with the Debian archive using apt-get. Sometimes, however, I install programs using dselect. After upgrading to the latest Debian archive using apt-get update/upgrade, I got the following message while running dselect: The following packages will be upgraded: openssh-client openssh-server It happened on two different similarly configured machines. I'm pretty sure this has never happened to me before. I have always thought that upgrading using either apt-get or dselect (using the apt method) were equivalent, at least with respect to staying current with the archive. Am I missing something major? Thanks for any illumination. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] how to clean grime off old computer MB?
Douglas A. Tutty wrote: Hello all, I have a couple of new-to-me old computers. They've been well used in what looks like a normal office environment and they're a bit grimey inside; not just dust that blows away. I figure that I should clean that off so the dust doesn't act like a thermal insulator but I'm unsure what to use, since air alone isn't doing it. I don't want to remove e.g. the CPU from its socket. (P-133, socket 7). All socketed part must be removed for cleaning. What have you used sucessfully? Use a dishwasher or clean manually with soft brush, detergent and hot water. Rinse with alcohol and dry with compressed air or heat gun. This is at home so I'm not set up for, e.g. a chemical bath. Do not use any other chemicals or solvents. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems after latest etch3 xserver upgrade
Upgrade again. It's fixed now. For details eee my post entitled Update: Re: GTK update problems. The fix made into the archives yesterday. Angus Auld wrote: Greetings, I had no apparent problems with the xserver-xorg-core/xnest upgrade from 2:1.1.1-21etch1 2:1.1.1-21etch2, but with the latest upgrade to 2:1.1.1-21etch3 I have noted that I am no longer able to use vlc media player. I got BadAlloc error. I forced a downgrade to the 2:1.1.1-21etch1 (why wasn't I given an option to downgrade to the etch2? It isn't shown at all). Alas, vlc still refuses to run and I get the BadAlloc error. I haven't noticed any other anomolies besides with vlc. How can I get my vlc back? Any thoughts greatly appreciated. TIA. -- Angus ##Linux Laptop powered by Debian Linux## ###Reg. Linux User #278931### Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dist-upgrade problem (was Re: /etc/modutils/0keep: line 9: keep: command not found)
tom arnall wrote: i attempted the distr-upgrade and after i rebooted did: [EMAIL PROTECTED]:~$ uname -r 2.6.16.4 so i did the distr-upgrade again. following is the session output. '31 not fully installed or removed.' is where it gets interesting: [EMAIL PROTECTED]:~$ sudo apt-get dist-upgrade It was doomed from the start. apt-get does not have the intelligence, as do the apt front ends, essential for all but the most trivial upgrades. Of those I can only vouch for personal favorite, dselect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dist-upgrade problem (was Re: /etc/modutils/0keep: line 9: keep: command not found)
tom arnall wrote: On Sunday 20 January 2008 11:46, Marty wrote: tom arnall wrote: i attempted the distr-upgrade and after i rebooted did: [EMAIL PROTECTED]:~$ uname -r 2.6.16.4 so i did the distr-upgrade again. following is the session output. '31 not fully installed or removed.' is where it gets interesting: [EMAIL PROTECTED]:~$ sudo apt-get dist-upgrade It was doomed from the start. apt-get does not have the intelligence, as do the apt front ends, essential for all but the most trivial upgrades. Of those I can only vouch for personal favorite, dselect. judging from the menu for dselect, there does not seem to be a way to do a dist-upgrade, only install like with 'apt-get install'. That's correct. I never explicitly upgraded from one distribution to another with dselect. I merely pointed to the newer distribution's repository (via sources.list) and dselect did the rest. I think dist-upgrade is an apt-get specific thing, and I'm not exactly what it does, other than repeatedly break users' debian systems and thus prompt frequent problem reports here. Nevertheless if you follow through with dselect then I think it will probably recover your system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dist-upgrade problem (was Re: /etc/modutils/0keep: line 9: keep: command not found)
tom arnall wrote: Marty, should i be concerned about the following. i did this without pointing sources.list to the new repository. Well, fix that. :-) [EMAIL PROTECTED]:~$ sudo apt-get dist-upgrade It's a typical cascade of errors caused by the first few individual package dependency problems. Again I don't know what dist-upgrade did, but dselect should recover or at least fix most of the problems, assuming you address the permissions issues in /etc raised by Daniel and point to the right repository. Good luck. Keep posting if you have problems. If may be a hard slog, but you can probably be walked though this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dist-upgrade problem (was Re: /etc/modutils/0keep: line 9: keep: command not found)
tom arnall wrote: On Sunday 20 January 2008 12:37, Marty wrote: tom arnall wrote: Marty, should i be concerned about the following. i did this without pointing sources.list to the new repository. Well, fix that. :-) [EMAIL PROTECTED]:~$ sudo apt-get dist-upgrade It's a typical cascade of errors caused by the first few individual package dependency problems. Again I don't know what dist-upgrade did, but dselect should recover or at least fix most of the problems, assuming you address the permissions issues in /etc raised by Daniel and point to the right repository. Good luck. Keep posting if you have problems. If may be a hard slog, but you can probably be walked though this. thanks for the help Marty. i have decided to do a reset and reinstall. i broke my system doing the 'chmod -R 777 /dev' and i think i just need to bite the bullet and do what others recommended back then. not doing it and asking for help with some of the consequent problems is really a bit much ;o). tom arnall arcata Good luck. It sounds like your best option for now, but for the record I don't think it would any big deal to fix your system. I've made worse mistakes, but I also realize that not everyone has the time or inclination to perform surgery on a broken install in the name of science or hack value. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
