Yes, but while there try to give usable Linux driver, there completely failed to support a recent leading standard distribution like Debian with a native compiler build system and all the fun and efficient tools. There are stick to an outdated Timesys distribution with an unbelievable obsolete build architecture. There still use static dev over udev, proprietary kernel driver build instead dkms, and no packaging.
There urgently need to evolve from a 'hardware staff that try to code application' point of view to 'software staff use standard distribution to dynamically load hardware capabilities' point of view. There have the advantage on the hardware but obfuscate it by an inappropriate software stack.
Going with AMD is an old idea as Altera was basically a Intel spin-off from the beginning. But this path will expose even more there products to a market where support for standard leading distribution is required and obsolete outdated almost proprietary bullshit rejected.
This was the most simple and useful USB function and there removed it. It allowed to play with any computers, TVs, or printers with high speed. Compared to MSD, the "new" protocols are slow and poorly supported.
There removed MSD for the wrong reasons as there is technical solution to provides a snapshot of the internal filesystem as a external view to avoid corruption.The btrfs filesystem support snapshot for example and a gateway could translate the resulting snapshot view in a other filesystem format like FAT32.
Thanks for the offer, but I don't plan to climb so high mountains even if I live in the middle of some of them. I enjoy walking the summer and ski the winter, but no high performance sport for me:-) I will probably take the panoramic cable car with my children someday.
I think I can recognize the Mont Vélan immediately behind the right on the Dent du Géant and even the Mont Rose at hit right on the horizon. Impressive, this is over 70km away from the point of view.
In fact the photo was taken precisely from the lower side of the cable that act as the aerial pylon of the Mont-Blanc Panoramic cable car. If you zoom you can follow almost the full installation but the blurred part before the Gros Rogon pylon buildings. http://www.remontees-mecanique...
I wrote Dents du Midi by mistake because there take most the view from my window:-)
No need to be billionaires and no need of helicopter. This is a cable car arrival and the price is far lower than with an helicopter, at least from the Italian side. From the French side the travel is more expensive because this is a long travel including a impressive 5km panoramic track with an aerial pylon.
This the new Helbronner cable car arrival connected to the Italian side and to the Aiguille du Midi on the other side with the famous Mont Blanc Panoramic cable car: http://en.wikipedia.org/wiki/V... The new Italian side is due to open this summer.
Désolé, the one with the crane is the new Helbronner cable car arrival that will normally open this summer: http://www.cordeemontblanc.eu/... The article emphasis the new cable car from the Italian side, but the arrival is also connected to the Dent du Midi by the Mont Blanc Panoramic cable car (la Vallée Blanche).
The Dent du Midi is visible on the photo almost on the opposite geographic side of the photo if you zoom.
I remember that the WMs situation was far worse regarding ICCCM. Bad behavior between the WM and the apps was usual. So I am really not choked that the development of a complex feature like CSD generate some bugs.
Of course only projects that add features are likely to add bugs. If you are perfectly happy with a specific conservative distribution, then just use it. But don't ask motivated developers to not innovate.
I still fail to understand why you want to use systemd-logind with an other init system. It's like trying to use one of the postfix binary without postfix infrastructure. I can't get it.
The client side decoration transition will certainly not limited to Gnome. KDE is also investigating something in that direction and will is likely to trig similar kind of bugs someday.
My personal opinion is that CSD has a future only is the WM has a very good GUI to manage the applications. This is the trend in most smartphone GUI and this is for reason: CSD is space efficient, but SSD is more reliable.
On a embedded system I have build using Debian Jessie, systemd is very verbose, more than sysvinit in my opinion. I wonder if the fact that systemd don't say so much in your case is not the result of a Fedora choice to make systemd less verbose by default.
I agree with you. Some project take time to get accepted and every bug is potentially a drama. This is nothing new, some venerable UNIX projects have also pass trough similar problems. We tend to forget this because there are now regarded as good old stable, but this was not always the case when there was published.
You can perfectly run Gnome applications on a KDE desktop as you can perfectly run KDE applications on a Gnome desktop. If you can prove the contrary, please report the problem.
And why did you complain on systemd not displaying something if the problem is completely unrelated to systemd (it could be a kernel/udev issue)? Now I agree that something is really wrong if you can't at least get a text login console, but again if it's a kernel hand, systemd can't magically bring something on the screen.
I don't say that it impossible that systemd is in fine the cause of your problem and that fix is needed to solve your case. But without more information is't both impossible to clearly prove that's a systemd bug, and impossible to create a fix if it's the case.
I never say to report directly to systemd project. Please report first to the Fedora community.
I don't know Fedora, but on Debian you can install sysvinit or upstart as a systemd alternative to help testing if the bug also show without systemd.
Did you understand that you compare a file manager based on a web browser to a login deamon???
Anyway systemd-logind uses the systemd API and Konqeror uses the KDE API (many of them actually) and Qt API. What's the problem? The dependency on the respective API is no more or less on the two example. Also, the two applications rely on D-bus and so indirectly depend on the services there expect to use on D-bus.
From what I remember from the time when dbus was created, the main issue at that time was that there was too many different messaging systems and, in addition to some technical issues, none was gaining enough consensus to normalize the situation. Both Gnome and KDE have experienced how difficult it was to change the messaging system only to found that there are each duplicating many works in a incompatible way.
The requirement to define a strict binary protocol was found to be the best way to normalize the situation. And this was a big success: since dbus is used by Gnome and KDE, all the low level services can publish an API that can be used by both projects. The initscripts didn't follow this trend and are now regarded as obsolete because there are unmanageable from dbus. I hope this show how normal is the central position of dbus into systemd.
Slashdot Mirror
Don't forget that Intel need a AMD64 license for all there x86 64 bits CPU.
Yes, but while there try to give usable Linux driver, there completely failed to support a recent leading standard distribution like Debian with a native compiler build system and all the fun and efficient tools. There are stick to an outdated Timesys distribution with an unbelievable obsolete build architecture. There still use static dev over udev, proprietary kernel driver build instead dkms, and no packaging.
There urgently need to evolve from a 'hardware staff that try to code application' point of view to 'software staff use standard distribution to dynamically load hardware capabilities' point of view. There have the advantage on the hardware but obfuscate it by an inappropriate software stack.
Going with AMD is an old idea as Altera was basically a Intel spin-off from the beginning. But this path will expose even more there products to a market where support for standard leading distribution is required and obsolete outdated almost proprietary bullshit rejected.
This was the most simple and useful USB function and there removed it. It allowed to play with any computers, TVs, or printers with high speed. Compared to MSD, the "new" protocols are slow and poorly supported.
There removed MSD for the wrong reasons as there is technical solution to provides a snapshot of the internal filesystem as a external view to avoid corruption.The btrfs filesystem support snapshot for example and a gateway could translate the resulting snapshot view in a other filesystem format like FAT32.
Thanks for the offer, but I don't plan to climb so high mountains even if I live in the middle of some of them. I enjoy walking the summer and ski the winter, but no high performance sport for me :-) I will probably take the panoramic cable car with my children someday.
Mont Blanc is the highest mountain in central Europe.
FTFY
Sadly the Wikipedia link show very little of this work and the external link is broken.
I think I can recognize the Mont Vélan immediately behind the right on the Dent du Géant and even the Mont Rose at hit right on the horizon. Impressive, this is over 70km away from the point of view.
There is a icon to get full screen view on the right lower corner. Work perfectly on my 4K 40" screen at least with Chrome.
In fact the photo was taken precisely from the lower side of the cable that act as the aerial pylon of the Mont-Blanc Panoramic cable car. If you zoom you can follow almost the full installation but the blurred part before the Gros Rogon pylon buildings.
http://www.remontees-mecanique...
I wrote Dents du Midi by mistake because there take most the view from my window :-)
No need to be billionaires and no need of helicopter. This is a cable car arrival and the price is far lower than with an helicopter, at least from the Italian side. From the French side the travel is more expensive because this is a long travel including a impressive 5km panoramic track with an aerial pylon.
http://tools.wmflabs.org/geoha...
This the new Helbronner cable car arrival connected to the Italian side and to the Aiguille du Midi on the other side with the famous Mont Blanc Panoramic cable car: http://en.wikipedia.org/wiki/V...
The new Italian side is due to open this summer.
My mistake, this is the Aiguille du Midi instead of the Dentd du Mid.
Désolé, the one with the crane is the new Helbronner cable car arrival that will normally open this summer:
http://www.cordeemontblanc.eu/...
The article emphasis the new cable car from the Italian side, but the arrival is also connected to the Dent du Midi by the Mont Blanc Panoramic cable car (la Vallée Blanche).
The Dent du Midi is visible on the photo almost on the opposite geographic side of the photo if you zoom.
I remember that the WMs situation was far worse regarding ICCCM. Bad behavior between the WM and the apps was usual. So I am really not choked that the development of a complex feature like CSD generate some bugs.
Of course only projects that add features are likely to add bugs. If you are perfectly happy with a specific conservative distribution, then just use it. But don't ask motivated developers to not innovate.
I still fail to understand why you want to use systemd-logind with an other init system. It's like trying to use one of the postfix binary without postfix infrastructure. I can't get it.
The client side decoration transition will certainly not limited to Gnome. KDE is also investigating something in that direction and will is likely to trig similar kind of bugs someday.
My personal opinion is that CSD has a future only is the WM has a very good GUI to manage the applications. This is the trend in most smartphone GUI and this is for reason: CSD is space efficient, but SSD is more reliable.
The twos bugs you linked was fixed.
On a embedded system I have build using Debian Jessie, systemd is very verbose, more than sysvinit in my opinion. I wonder if the fact that systemd don't say so much in your case is not the result of a Fedora choice to make systemd less verbose by default.
https://wiki.debian.org/system...
The curious thing is that the systemd binary only read unit files and execute command accordingly. How can it bug because of a USB device?
I agree with you. Some project take time to get accepted and every bug is potentially a drama. This is nothing new, some venerable UNIX projects have also pass trough similar problems. We tend to forget this because there are now regarded as good old stable, but this was not always the case when there was published.
You can perfectly run Gnome applications on a KDE desktop as you can perfectly run KDE applications on a Gnome desktop. If you can prove the contrary, please report the problem.
And why did you complain on systemd not displaying something if the problem is completely unrelated to systemd (it could be a kernel/udev issue)? Now I agree that something is really wrong if you can't at least get a text login console, but again if it's a kernel hand, systemd can't magically bring something on the screen.
I don't say that it impossible that systemd is in fine the cause of your problem and that fix is needed to solve your case. But without more information is't both impossible to clearly prove that's a systemd bug, and impossible to create a fix if it's the case.
I never say to report directly to systemd project. Please report first to the Fedora community.
I don't know Fedora, but on Debian you can install sysvinit or upstart as a systemd alternative to help testing if the bug also show without systemd.
Did you understand that you compare a file manager based on a web browser to a login deamon???
Anyway systemd-logind uses the systemd API and Konqeror uses the KDE API (many of them actually) and Qt API. What's the problem? The dependency on the respective API is no more or less on the two example. Also, the two applications rely on D-bus and so indirectly depend on the services there expect to use on D-bus.
https://packages.debian.org/je...
The Gnome 3 windowing issues have nothing related to systemd architecture (and I personally prefer XFCE or MATE).
From what I remember from the time when dbus was created, the main issue at that time was that there was too many different messaging systems and, in addition to some technical issues, none was gaining enough consensus to normalize the situation. Both Gnome and KDE have experienced how difficult it was to change the messaging system only to found that there are each duplicating many works in a incompatible way.
The requirement to define a strict binary protocol was found to be the best way to normalize the situation. And this was a big success: since dbus is used by Gnome and KDE, all the low level services can publish an API that can be used by both projects. The initscripts didn't follow this trend and are now regarded as obsolete because there are unmanageable from dbus. I hope this show how normal is the central position of dbus into systemd.