A lot of people care about video over LAN, which has many uses. Why wouldnt they? There are those who want to be able to have their own video station or use video conferencing capabilities. This is an application layer thing so can work over LANs or WANs.

They may or not release a proposed rule, this is true. however that does not change the fact that they did not.

Fail. That is not true. Blatantly untrue.

Show the link to the rule. Maybe they will release it AFTER they vote on it but it was not available yesterday. You sir are the idiot. You dont know what your talking about.

I double checked and you are WRONG and have absolutely no idea what you are talking about. There is no public copy of the rule. Just the summary which is NOT legally binding. If this is so benign then why dont they make the rule available? How can anyone comment or have an opinion on a rule they have not read and therefore they do not know what is in it.

There is no rule available regarding what will be voted on Thursday. You are mistaken about this, if the rule is there, where is it? What you posted was a Summary which has no binding legal effect. Why not simply post a link to the rule?

NO! You are wrong! You don't know what your talking about. There is no online copy of the rule that will be voted on, on Thursday, that I could find anyway. That was a SUMMARY! It has absolutely no legal bearing. We have no idea whats in the final rule.

If its all so benign, then why is the regulation itself secret and not available for public review. Also, the size of the regulation at 320 pages is very suspicious, its hard to understand how so many pages could be needed for what seems like a few simple rules.

A free market works to weed out abusive bad companies that provide bad service and products IF there is a lot of consumer choice, markets can work very well. The reason markets do not function well with broadband is its a near natural monopoly, or a natural duopoly rather. Because of the huge investments needed in the infrastructure its only possible for a few companies to be involved. So, the effect of the market is weak to non-existant, thats why regulation of these kinds of things can be beneficial.

There are some other cases such as consumer safety. If you didnt have regulation of restaurants, when people are harmed from food poisoning, those restaurants might go out of business yes, but food poisoning is too a high a price to pay for relying on market response. The market response tends to be reactive, and sometimes you have restaurants run by the incompetent who dont care or understand the threat to their business that food poisoning cases would involve, people should not pay with their health until we can find out what restaurants are badly run. So, pre-emptive regulations that prevent food poisoning in the first place is well justified. Other things about restaurants such as the taste of the food are unregulated however since they are not deadly and the market can be left to react to this.

Ok, this stuff is just too creepy and fucked up. Frankenstienish. Definitely worthy of the whatcouldpossiblygowrong tag. Its just too dangerous for this kind of meddling to be legal.

It is a sensible design. /usr is so called because it is where user installed programs and their supporting stuff usually go, in contrast to /bin which is your main system programs. bin means "binaries", which is exactly what is in there. /dev means "devices", again, thats whats in there. We used abbreviations to reduce the amount of typing needed when using the command line. Hundreds of tutorials and books have been written about the directory structure and explain exactly what it means. /etc really is fine, it does not refer specifically to configuration, but its been in use forever, its just not important enough to change something that is a part of the tradition. If your enough skill to modify config files, good for you, and you can learn what /etc means. I came to Unix from Windows wanting to learn its way of doing things. I tend to place a lot of importance in following the Unix traditions.

I am not averse, to providing additional functionality on top of the Unix canon, but I am for full adherance to Unix conventions, additional functionality can be added on top of that. For instance, in gedit, the user is put by default in their ~Documents folder when they open and save files, so they dont even need to know what /etc is. /etc is for literate users and we can learn what this stuff means.

Linux should have a committment to old hardware. One big issue is the Wayland thing. Wayland supports a grand total of 3 adapter families or so. It only runs on the latest and greatest. There is a lot of old hardware that is supported well by the X server, so the X server needs to continue to be provided for that fallback.

I actually think that Wayland is potentially worse than systemd by far, if we do not allow people to run all their GUI programs as X applications. X needs work on security hardening for sure. But, Wayland puts hardware drivers and address space *inside your web browser*. Excuse me for being a little skeptical. Wayland introduces a very rigid desktop model where its hard to change your window manager without a complete restart of GUI, where the need for network transparency has not been addressed well enough,

I agree that runlevels should be a part of the systemd model. Other basic concepts that systemd was trying to do are not bad. Its hard to argue that a system administrator should not be allowed to configure a certain program to run when the NIC goes up or down or when there is some other system event. It sounds as though systemd's execution of these things may be lacking. systemd should provide support for traditional sysv init facilities as well, if thats what you want to use.

As for binary logs, configuration, I think the system admin should have the choice between binary and text based. Binary has some advantages, in that they can be easily programatically accessed and still be accessed by text based utilities, since there is a hash or b-tree index, a large log or config database can be easily searched without having to do a scan of the entire file. Its also possible that binary logs could be used to generate a text version of the log, if you want to use the vi, and as well to the text file only, without anything being kept in the binary log. So the choice betwene binary and text should be your choice, it shouldnt be an either or thing.

I can definitely agree that with such a core part of the system there has to be a high degree of focus on quality, it needs to be well documented and should not have major bug problems in the stable releases.

The "not very *nix like" is suspect. As long as it supports the traditional unix initization System V facilities, such as the rcX symlink directories and maintains backwards compability with these traditional forms of initilization, its keeping a unix like quality. The addition of new functionality does not mean it is taking away older ways of doing things, and does not mean you are forced into using these new capabilities. If you dont like that the web server is starting from systemd's own method, you just move its initialization over to the old System V facilities.

Its sort of hard to argue that you should NOT be able to set up the HTTP server to be stopped and started with the NIC or run other processes triggered by other events if you want to, and it seems thats what systemd's opponents are saying, "you cant do it that way, you shouldnt be allowed to have that functionality".

The basic concepts of what systemd does is good, this does not mean the execution has been particularly great.

I want to point out that systemd does not take away your capability to use traditional Unix init scripts, these can be easily configured to be spawned by systemd. If you want init scripts, just disable your stuff from starting in systemd's own facilities and move it to your own init scripts. Problem solved. It is odd that people who think that systemd providing additional functionality is taking away something from other people. The fact is, it does not. As for the "single process" issue, that I believes refers to the cron like functionality in systemd. If you really want cron in a seperate process, you can do that by simply starting a seperate cron program and having your cron jobs run by that rather than systemd. Systemd does not preclude you from using other programs for certain functionality. Its not like "now that systemd provides X functionality I MUST use systemd for that!".