Does Unix do P&P?
trooks
Posts: 228
Unix in all its' many guises keeps popping up here.
Do any iterations of Unix do Plug and Play?
I am constantly swapping thumb drives for different apps and projects and need to know if another OS can handle that on the fly like Win does.
Expiring minds want to know.
Tim
Do any iterations of Unix do Plug and Play?
I am constantly swapping thumb drives for different apps and projects and need to know if another OS can handle that on the fly like Win does.
Expiring minds want to know.
Tim
Comments
No idea about BSD's. I guess they do.
Honestly, this really isn't a UNIX question as much as it is a utilities one.
Something like automount runs on the UNIXes that can handle on the fly thumb drives. That is open source too. So really, it's about whether or not that UNIX has it running. Most do now. But you can always build it and set your UNIX up with it too.
BTW, IRIX old as it is throws new filesystems on the desktop, where a double click leads you to assign a mount point.
And that is what you need to know. No drive letters. All filesystem devices appear in directories.
"/" is "My Computer" and your C drive all i n one. The directories you see there exist on your system disk, which contains your UNIX.
A mount point, is one of those directories which points to additional filesystem devices, such as your thumb drive. BTW, if you put stuff in a mount point directory, it won't be accessable so long as a device is mounted there. I would sometimes put a file with a fun name to show the disk isn't mounted.
Typically, a scheme, such as "/mnt/cdrom /mnt/media/usb1" is how the portable drives are found, and you can change this, or make symbolic links to do things like have a thumb drive apprar on your desktop, or home directory, if the OS is not configured to do that.
In theory, you don't have to format in FAT16 or FAT32, you can do it in EXT2 or EXT3 which are Linux alternatives. But I never do as there once was a lot of discussion that the wear features required FAT16 or FAT32.
And of course, if you are going back and forth between Windows, Apple, Linux, and Unix... the FAT16/32 seems to be generally accepted.
+++++++++++
And so, regardless of what OS I prefer, I keep going back to Windows to reformat these to preserve longevity. Am I being silly?
On a basic level, these are block devices.
If there is no formatting, you read and write blocks. The next layer up from that is partition support. Above that is filesystems. Both of these simply put specific information into the blocks to be understood by programs that have filesystem support, and that is what formatting does.
They make formatting utilities for Windows because Windows does not offer the basic tools needed to get the job done, or using them is not expected of users.
Unix does provide those things, and one can even manually format by putting the data onto the device as a block device. Nobody does this, but you can, if you want to.
Finally, the number and nature of users favors utilities for windows. That is where the masses are. People running other OSes are assumed to know what they are doing, or the OS offers the tools people need, like Mac OS Unix does.
This is not just a utilities question. The kernel sits between all hardware and the applications. The kernel has to detect when devices come and go and notify user space some how.
I do all my SD, USB Stick, external drive formatting in Linux. I have don't recall having issues moving things between Linux and Windows. On the occasions when SD cards are misbehaving neither Windows or any SD vendor tools have helped save them.
But in the early days, some cameras were asking for reformatting. And the user's group for my first EEEpc 701-4G was very divided on the use of EXT3 versus FAT16/32.
So in many cases, I have had to reformat just to get back to normal after being led this way and that. And in other cases, I have reformatted to merely wipe clean a card.
Most recently, I had a 2Gbyte SDcard fail on my Palm Zire72 that I have been automatically writing backup to for many years. So I reformatted it and it now seems to be behaving fine.
Using the manufacturer's reformating software seems to bring the card up to its largest capacity for me. Results from others have varied.
So the Kernel needs to recognize the device and it ends up in the device table. On older kernels, this didn't happen, unless it was requested. Like the SCSI bus, would need a reset, then an enumeration, etc... at which point, a device would appear in the device table.
From there, it's about things like automount, which will scan the device table, and perform various tasks, like say dropping an icon on the desktop, or actually mounting the media.
I'm pretty sure most UNIXes today have support for the basic device handling. Get it plugged in, and it shows up in /dev/whatever If that's not really there, a user would then have to run something that triggers those actions, of course.
Was keeping it a bit too simple. Agreed.
Mentioning systemd has just raised my blood-pressure, I need to walk away now.
Who continues to reinvent UNIX poorly?
This big mess will have to become an entire operating system itself, which marginalizes the operating system it runs on. Nobody needs this. Those who want it either are seeking to control way more than they should be entitled to, or have simply not yet understood what UNIX is all about.
Neither is good.
Back in the Windows NT days, there was a similar discussion regarding graphics being moved to Ring 0 to make a few improvements. The trade off was stability, and to some degree, hiding things from the user, making DRM more possible.
It took a really long time to deal with that crappy decision, and still it is possible for a user mode program to ask the graphics system something which takes the whole machine down. Nuts!
Replacing init with this mess will have similar implications, and most importantly, it will prevent "roll your own" Linuxes, because having it be successful would require applications call it's API, and that API will touch most everything!
Suddenly, Linux gets defined by the mess of whoever owns systemd. That isn't how we are suppoded to do things in OSS land.
Frankly, I am stunned this isn't laughed right off the stage.
Let me just say, systemd IS NOT THE UNIX WAY. 'nuff said.
Ray
Not quite. The current stable version of Debian (Wheezy) does not have systemd by default, it seems to have gone into the next release candidate (Jessie). I only recently installed Jessie on one machine and had not noticed they had slipped that in. Looking at that machine now I only see systemd-logind which seems to be a login manager.
Certainly my gripes about Ubuntu started long before systemd was on the radar.
Hey, what's wrong with Gentoo? It's great.
Fear not, there is always "Linux From Scratch": http://www.linuxfromscratch.org/
Edit: This article explains that you do have to do some work to activate systemd on Debian Jessie:
http://major.io/2014/05/20/switching-to-systemd-on-debian-jessie/
Certainly on this Jessie machine my init process is actually the normal init executable. Rather than systemd. So Debian is not totally buggered up...yet.
Edit: Electrodude, sorry I read the meaning of your post backwards.
Gentoo is great. I ran Gentoo for years a while back.
systemd has been pushed through by politics. It's horrific in almost every possible way.
Too much coupling between separate systems.
Too much of an attack surface (time to fuzz dbus methinks...)
Lives in PID 1.
Seriously idiotic.
USB drivers just work, USB serial just works and sticks to nice ttyUSB0 if it's the only device and reconnects as well on P&P. Windows kills me with having to find out it has assigned the serial device to COM87 and I have to disconnect the terminal and reconnect for it to work. A real show stopper.
The fact that the first one plugged in is always ttyUSB0 on Linux is actually pretty annoying for one of my projects that involves multiple serial ports. If I plug things in in the wrong order, BST and my datalogger program will open the wrong ports. If I only have one plugged in and want to also plug the other in, I sometimes have to unplug the one that's already plugged in to get them to have the right names. The fact that one doesn't have a good connection doesn't help either, so if my ttyUSB0 gets disconnected and then reconnected before the program reading it has time to close the port, the new reconnected one gets ttyUSB2 even though only 2 devices were ever connected. On OSX, however, USB serial ports get names like tty.usbXXXX, where XXXX is unique for that converter chip. I would just have to tell my datalogger to open its tty.usbXXXX and tell BST to open its tty.usbYYYY, and, no matter which order I plug my devices in, it would work. I should look through my kernel configuration to see if I can enable this.
You can bind serail devices to static names very easily. Then as a particular device comes and goes it will always get the same device name. See here: http://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-a-static-namehttp://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-a-static-name
For the full power of udev rules go here: http://www.redhat.com/magazine/002dec04/features/udev/
The theory behind the move was to make sure that interfaces came up in a consistent and predictable manner. Same principle, abuse of udev rules to ensure consistency.