Not sure if it's related but my system is really lagging. In fact unusable typing this on my phone. I noticed in the service.lightdm file a comment about only using this structure until the dms catch up and that it is starting lightdm directly and ignoring all configuration files. That explains a lot. I also saw my logs filled with errors. I am pretty anal about keeping it clean so something has changed more than lightdm on my system at least.

I switched to xdm and got to a login screen with no issues.  System is still laggy for example can't use terminal at all.  I am not sure what is going on this may just be a sid issue but I have not seen any warnings on upgrade and don't see anything on googling. Hmm. Strange times.

This may sound stupid but do you have java8 installed?  I don't have any of those folders that it is trying to create and would suspect you don't either.  Specifically looking at :

Quoteupdate-alternatives: error: alternative path /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/javaws doesn't exist
dpkg: error processing package icedtea-netx:amd64 (--configure):

Which looks frighteningly similar to the crap I am getting with lightdm where it is trying to call a file from a path that does not exist.  If I get my lightdm thing sorted I will try and duplicate this.  But seems like something in the way this is being called is amiss.  Those error codes would indicate the same that something is being asked for and isn't there to be found. fwiw

I can't imagine that startx would be removed.  That is curious.  Just checked again and I have no issues using startx.  Still no idea what they have done to lightdm and why it is failing but clearly it's structure has changed.

Just an update.  If I run startx - get into an xsession and then run my lightdm default.sh as a user it runs with no errors and it seems I am in a lightdm session.  Soooooooooo I would speculate that during boot lightdm is calling for a file that isn't there and defaulting to failure.  More as it unfolds.

Quote from: VastOne on September 19, 2014, 06:21:36 PM
Aye.. Suffered through a power outage last night and when I turned the machine back on I am getting the same exact thing. I noticed an update to LightDM yesterday and I am sure this is the issue.  For the record, please explain how you are restarting X so that others may learn from this

Not really much to it.  When the system quit complaining about lightdm it gave me a login prompt.  Logged in as my user and ran startx.  Of course that caused other issues so it's not ideal.

I have done a little research and noticed that things for lightdm are completely different.  For example lightdm-set-defaults is completely gone and things have been moved around.  Of course I would suspect that lightdm which is horribly documented and is pretty much made for F_ubuntu is probably looking for some upstart conditions.  I am speculating here but ... grrr. Will look further.

I hadn't rebooted for a while ... oh lets say a couple of months and when I did lightdm seems to be failing google gives me some bug reports but no answers.  I can start x with no issues logging in and running startx but I see the same issues in my logs and running lightdm in test mode repeats the same error:

Quote*** Error in `lightdm': double free or corruption (fasttop): 0x00007f6f371e8ab0

Has anyone else seen this or does anyone have a hint to a solution?

Thanks

The only thing I tend to do differently than what you have there Grey Wolf is I like to have my things like ff as functions rather than as aliases.  It's a minor difference but organizationally it helps me to keep them separate.

I also use cdargs as opposed to aliases for movement.  But those ../.../.... are pretty nice.  Might have to rethink that.

Nothing rambling about that.  One riff begets another. Thank you for the compliments guys, not sure they are deserved but thank you. 

A couple of points to add.

1. Define Bloat - similar reaction to the word but I define bloat as this.  If I am doing a new install and have a problem with sound and pulse audio the first thing I do is set up alsa to test and get working.  Once I have alsa working I know that I can get Pulse to work.  I would never reverse that process, I would never install Pulse to see if I could get alsa to work.  The reason is that alsa is simple, clear and elegant.  It allows for easy diagnosis and it's very easy to get under the hood and see what is happening.  In my experience pulse is not, there are things that are obscured and harder to track down.  Therefore I would say that pulse audio is bloated. Sorry that is indeed pendantic.   Or perhaps it is bias but I could use other examples.  I think you get my drift though.

2. I mentioned elegance. I like elegance, to me it is essentially looking for the "middle path" not in a fence sitting way, but in a right choice way. (For Reference see "Buddha aka that big guy"). VSIDO is to me a most elegant distro.  The middle path here is clearly to go with systemd and leave the user the choice as you suggested. A choice that is not unlike the choice of pulse, Gnome, openbox, mutt, etc. In this case should I or others choose an alternative init it's just that, their choice and it is open to all that choose VSIDO.  This is not like Debian or not Debian.  I was attempting to suggest that the choice really is the end users and for all intents and purposes that choice will remain.  I was also attempting to suggest that Debian seems to agree and that in the interim there seems to be nothing stopping anyone from making that choice.

3. Fear of the Einstellung Effect. My fear that stems from the knowledge that once people have a good solution there is a tendency to find it hard to move on or look for an even better solution to a problem. Call it stasis, following the leader, etc. By all measurements systemd is at present an acceptable outcome for the init issue but it is far from ideal or even great depending on the perspective you have.  It has a long ways to go for some of us to even call it a good solution.  But since it has passed into Debian it will have momentum, etc. I can think of quite a few things that got this far and just never went any farther.  In this particular case I am more worried about good becoming the standard level of acceptance.  The reason being that the work/advancements I see being done on systemd are being done toward adding more tools into the system it controls and more things for it to control rather than fixing what it currently does.  That's scary to me.

In other words one of the great things about this entity you have created is that VSIDO is very much a beginning or jumping off point.  Too many distro's are seeking to be the end point and that is why we all hop away from them.  This is the middle path, there is no end only a path and only a starting point.

Oooh I hope that doesn't sound too ego based or philosophical.  Really just the best way I can put into words what I am trying to say.  For you or others it may be something else.  This is it for me.

Forgot to add: No, it seems that you compared KISS to the Beatles and both to systemd??? Next you will be comparing lumping John Coltrane in with Kenny G.  Someone stop him before this point please 

Great addition OziT. I apologize for both the length and the Tom Robbins manner in which this is written. This had been on my mind all weekend.

I have seen the above discussed a couple of places but it only takes care of the initial part of the problem.  The fact of the matter is that using an init alternative is going to create breakage. 

There are going to be things, increasingly, going forward that are going to be built utilizing the systemd framework.  By framework I mean the obj's that systemd packages as a block.  In the alternative init's (excluding upstart for the most part but not completely) components are broken out and there are different handlers (this is the freedom of which I speak) that allow you to fork processes and make direct calls.  [I am really simplifying this a great deal for my own simple brain]

In systemd a lot of the low-level functions are bundled and this both limits what a developer can do as well as how he can do it but at the same time makes it easier to ignore these low-level calls.  It creates inefficiencies in handling but simplicity in functionality or simply put, there will be times where you can't really get there from here.  The bottom line will be an impact on maintenance, not so much today but tomorrow.  There are always going to be developers who don't accept this. 

The time I have been spending on this (not as much as needed) indicates to me that this impact will mostly be with the bells/whistles type gee-whiz stuff that we are not prone to using.  People who like things like VSIDO and Slack and other sparser distro's, people who are not running Gnome Desktop or KDE or all in one type solutions are not going to run into it.  Things that could require some effort would be things like Nautilus that integrate with those desktops and provide one click type solutions at a higher level, that are hiding the low-level work. 

I am speculating here, but I think what frustrated someone like IG (to a lesser extent myself) is that for his tools to work he needs access to those lower-level pathways and calls.  Without that access his ability to provide the stuff we know and love becomes drastically reduced (e.g. the ability to structure how the drives are called and get control of certain processes with Udevil or SpaceFM). Providing this under systemd will require either a fairly constant upkeep/impossiblity or limit the tools to non-systemd inits.  This led him to a "why bother" position and I can't say I blame him.

This over-arching problem is going to result in narrowing choices for the end-user.  There will be tools that we now know and love that provide in depth solutions and hacks that won't work anymore because access to those low-level processes won't be available.  They will be replaced with other tools that might or might not give the same info/access but will not be the same and example is the "improved" logging/journals that systemd offers.  Some will call this progress and perhaps they are correct.

The good news is that everything that works now with VSIDO would work with an alternative init.  Choosing an alternative init initially would be pretty painless but the fact is with rare exceptions (Pulse Audio anyone?) Debian rarely dumps a shiny new toy and goes back to a simpler more elegant solution.  Going forward these tools will probably continue at least for a good while to be maintained and probably some will continue in full development regardless of what Debian does.  The bad news is that there are going to be things that possibly will only work in the systemd environment out of the box.  Without looking into more detail I can't tell you how difficult the ports will be but I imagine that they won't be that heinous and possibly will be requiring only a script type solution.  It could require working together to try and get something to work at times and will require a committed community to support the distro.  Initially I think this is a ways out.  Few if any are immediately prepared to utilize much of systemd "infrastructure". 

I am not sure what a true feasibility study would look like.  I am guessing something like we are discussing here and maybe we can flesh it out as a group. 

Runit or its brothers would work well currently as would systemd. I don't think you could get away with splitting the installation path and just let it go at that.  Again, I am not really sure that anything won't work with a lower-level init system but it will require maintenance and some work. I do think that there remains a GREAT deal of resistance to systemd on a technical basis, that is a core group that is saying this is wrong because ... and that always leaves a door open in a community based project like Debian. 

Is it feasible that a distro could spin off and go with an alternate init?
   Yes, certainly.

Would it require a significant initial effort to do so?
   No

How would it limit the user experience?
   Initially it would probably provide very little difference between the current systemd environment.  Over the long-term this burden would increase assuming that systemd remains the init of choice.  If over time systemd grows into it's role as the init of choice it will develop more and more tools and apps that work symbiotically with it's feature set.  Undeniably though there will be progress on the other alternative init's and they too will offer increased features and work-arounds to the community.  I really believe that based on my research (again, limited as it is) that the difference in impact will probably be minimal.  I think there would be hiccups but that is kind of assumed with a cutting edge distro.  There also remains the basic fact that jumping from an alternative init to systemd is probably always going to be rudimentary but going the other way will be more difficult.

How difficult would it be to maintain?
   This is a harder call to make, at least initially.  I don't see a rush by the development community to embrace systemd. The red-hat bootlicker apps, those apps that depend on redhat for installed base will be all over it, certain large Debian installed base apps, the rest I think not so much.  I don't see a reason that a lot of the console type apps using lower level tools would change, etc.  People in this community (Debian/Linux) are always looking to get simpler and more efficient, I find it hard to believe that overall they will ever totally embrace systemd and it's architecture.  But this could be my head in the sand.  In answer to the above I think not very hard but in the end this is a guess.

What is the real argument against an alternative init?
   That is the question I am asking you.  What is it that Debian is bringing to the table here other than it being part of their standard bundle?

What other concerns/feasibility issues are there.

I understand the simple fact that this distro is founded on Debian Sid at its base. I also understand that part of the beauty of this wonderful distro is that it just works with very little effort and affords a fantastic balance of ease of use and freedom to have what you want.  The question is what the "cost" for this will be going forward.  If you look at it as a linear equation one side is now wildly out of balance.  You still have the ease of using Debian as a core but a great deal of freedom and in my opinion flexibility has gone away.  I am not sure that formula works for me anymore and not sure I can accept that price.  That is a personal choice of mine, I again can understand that most people would rather just go on down the road accepting the loss as a cost of doing business.  Sorry want to be pithy and interesting and humorous but really too much to do today.

Should of had a guinny myself.  I really need to spend more time on the actual call handling with runit v systemd.
I want to know

• What that cost actually is as far as freedom
• What impact would runit have from an upgrade/maintenance perspective
• Can I continue to install/add software/etc with minimal impact (say on the level of what I do to use flux or OB)

Just to be clear my problem is not with the basic functions of systemd at the init level but the journal changes, the overlap with other tools/the removal of specialized tools (there are going to be some quality stuff that Debian will be removing as time goes forward and the systemd people say "oh we are already doing that ... etc.) and the external processes and tasks it takes over. UNDER NO circumstances can I accept corrupt journals/log files.  That is as much of a no go to me as attempting to license the init functions is.  It's just an impossibility.

I've got 3 horses running this weekend and once that is done will have more time.  I apologize that my comments (re-reading them) do not seem well formed.  It's kind of I know what I mean but not how to put it.  I do agree with PackRat and his excellent comment regarding the boutique potential of using something other than systemd.  I can't assess that as either good or bad and I am not totally sure of the total impact on running a system that is "not quite" pure Debian.  As we have discussed ad infinitum this decision by the Deb leadership puts a fork in the road and where that fork takes me is really up to me.  I am not attempting to influence/persuade/demand that VSIDO or anyone else follow my path.  The information and discussion I am adding is meant as informative and conversational as again I don't want to waste anyone's time.  FWIW, I greatly appreciate ALL the comments and value the opinions of each of you, I feel lucky to have this forum to be able to essentially think out loud.  I am pretty sure Jedi will point out how wrong I am 

Quote from: PackRat on September 10, 2014, 09:36:19 PM
"..a plug and play SID system installable and re-installable in 5 minutes"

Looks like you want to stick with the Debian default then; the repos will be coded to work with it. Stray too far from that, and you'll be running the risk of becoming a boutique distro.

Quote from: ozitraveller on September 11, 2014, 12:37:10 AM
I hope nobody minds if I stick my 2c in here??

There has been a shift to systemd for many of the major distros, and I think they will not likely shift again in the near future.

For me, as a small distro owner/sole maintainer, I don't want to and haven't the time to stray too far from mainstream debian and increase my workload. And loose 100% compatibility with debian.

This is one of my hobbies and if it becomes "WORK", then I'll move on to something else.

I've closed the door on this. Until I see Debian support interchangeable init systems, then it goes in the too hard basket.

Hence my comment on the other thread, sorry if I offended anyone. 


Ozi

[edit] Ozi can't imagine what you said that might have been offensive.  I think we even agreed with you at the time that it had been talked to death.  But, again. If it has to be accepted we should really understand what we are accepting.  That was the point.[/edit]

I can't disagree.  That was really what I was trying to say with examples in my post above.  For my own personal systems I may well run runit or sysV but for a distro it would be a significant amount of work in maintenance, etc. That said, I also have some future projects that systemd is going to pose a significant hurdle to.

The finality of this decision (by Debian, the finality of the box it puts all of us in, the limiting of choices I mean) was part of what I was trying to communicate in my response to Jedi in the other thread.  The Debian decision really closes a great many doors, it's extremely impacting. 

Sorry for wasting anyone's time on this. 

I am not going to say I can accept this path and will probably at least play with BSD in the near term.

I have been looking at this and runit doesn't look that bad.  The question/concern/issue really is from an integration standpoint.  Since the beginning you have had very little for the end user to care about when installing or adding about anything they wanted. if you move along a divergent path (regardless of what that path is at this level) you are going to add "complications" to this.  It really is the elephant in the room with the whole systemd decision.  I had planned on adding some examples to make myself clear but time and some pressing issues have gotten in the way and I don't want to drop this or let it seem as if it has been dropped.  I can give a reasonable example of what I mean and someone can check me if I am wrong ... I had a pretty similar issue already so I think I get it tho

Lets say someone developed a program that takes dmenu and then autostarts it's daemon at boot.  Besides autostarting it's going to check to see what mounts you have include that in the menu.  Since the author was an ubuntu guy, this is written to be triggered by the upstart boot process, upstart calls.  Now I hate Ubuntu and want to run it in Deb for me.  The developer either will have to rewrite the calls and rebuild it to work with systemd or I will or I can't use it.  I don't think this is a constant issue but there are some things that will have to be reworked.  It's not trivial, I personally would not mind it much but ... 

Not so serious in the above example with upstart and systemd since they are the crowd favorites and we have already had canonical running roughshod over a great many people so most things have Debian installs versus ppa's but in the case of runit this might/will cause issues and will mean either a fair amount of work for our fearless leader on a regular basis or a complicated set of issues for the users. Again, I may be making this more complicated than it is and it might be rare or extremely rare (feel happy to correct me) but I do think it's something that people should be aware of.

Interesting seppalta will check that out.  I had been looking at NotablePDF which is a chromium extension.  I actually like it because most of the PDF's I am editing are docs from legal/Acctg/Banks and such that I don't want to do much but sign and fill. I really hate PDF in the whole but it's a necessary evil I guess.

I had heard great things about plex and have been trying it out with Debian.  Fact if you have audio/video/local media that you want to watch on TV this program is awesome.  Works incredibly well with chromecast and the picture/media handling is pretty impressive.  I have about 4 TB of movies/docs and another 3TB of music which Plex handles as well or better than anything I have used before (XBMC, Subsonic, etc.) You install the app like this thread explains https://forums.plex.tv/index.php/topic/51427-plex-media-server-for-debian/ Open the web page in your browser, add your media folders which is intuitive as anything, open flex with your phone and boom you are off.  I would recommend the 5.00 android app and setting up an account for the extras but within the time it took to scan my folders ALL of my media was available to my TV.  Really amazing.

Note: I have not gotten PlexHomeTheater to work but it too looks impressive.

This still doesn't give me what I want but I am guessing if I can get Google Remote Desktop to work I will be in the money. 

I usually just broadcast stuff from apps on my phone but of late have been wanting to watch certain videos from websites, well to be honest I want to watch live horse races when my horses run and they are only broadcast on certain sites so I have to use chrome.  But alas and alack I can't get chrome to play them.  Has anyone had anyluck using vlc or anything to chromecast websites or local videos over?   Plex?  Any recommendations at all?

Seems as if I am the only one who is interested in this.  But in case someone comes along before this all changes:

1. I can't seem to get google remote desktop to work - keeps asking me to reinstall
         It requires a reboot.  This is the only known method for casting hidden streams that some providers us, well other than deconstructing the page and hijacking the stream

2. Chromium doesn't see VLC at all in the options pages?
      True enough.  VLC is working for a straight streamcast extension but so far no good.  It seems Chrome will work but alas chromium does not use the same parsing methods so extension fails to load
3. I can play the videos in firefox but can't get them to the TV?
      False.  I can get some videos streams to work but these are the standard file formats etc. that I could just download and stream myself.
4. Does Roku do this???
      No Roku faces the same issues.  It is about content control really. 

Below I will add in what has worked for me.

Quote from: PackRat on September 07, 2014, 02:09:07 AM
I'm beginning to sense a purge and re-install of lightdm in your future.

Good call PackRat!  Should have gone that way from the start but I thought it was a config issue due to upgrade.

I am not on KDE but yes it seems a lot of things have been updating lately, many changes.