> Hi, I don't know if this is the correct area to post > these, if this isn't then please feel free to move it > to the designated area.
cc-ing opensolaris-discuss, which is probably better. I'm not quite sure what the program-team list is for, but I suspect it's for something rather narrow and more administrative in nature, not for free-wheeling discussions... > So far I love OpenSolaris, It's so much more > insteresting then XP. > But i do have some ideas. > > I think it's all good to say that people who use > other linux ditributions have to adapt slightly to > understand how OpenSolaris works, and offer support > for their immagration. But there's no help for those > of us coming over from Windows based systems! I am a > very able person on computers according to all my ICT > teachers over the years, and many of my friends come > to me for help. But this was very different! > > My 1st consern is installation of programs. It > couldn't be more difficult! Yes installing from the > Package Manager is easy, but thats the end of it. The > file system with all of the weirdly named folders > doesn't help when we (being the XP users) have no > idea what folder does what and where to move the > files. Typically you don't want to be fooling around at that level of detail if you're installing packaged software, especially if you don't know what you're doing. The defaults should be reasonable. And I expect installation will get easier/smarter as it continues to be developed. But that does _not_ mean looking more like Windows! (although I have seen some apps packaged with an "install wizard" that looks kind of similar) For an overview of (some of) the different locations (directories, not folders, please! "folder" is just a metaphor), see the filesystem man page, also online at http://docs.sun.com/app/docs/doc/819-2252/filesystem-5?a=view > Windows systems use *.exe files for applications and > also installing applications. It does all the hard > work for you in a simple GUI window. If OpenSolaris > could use *.exe 's or create a new file type which > does the same thing, it would not only benifit us > (ex-)Windows users but the every other user. Unix has historically never used filename extensions to identify executables. No .exe (or .com), no .bat, none of that. In most cases, file name extensions on Unix are just a matter of convention (although some programs, like the C compiler, may expect certain extensions to be used for certain types of files). The operating system itself really doesn't care about such things. That also goes for Linux, and maybe even for MacOS X, give or take compatibility with historical Mac-isms. Usually Unix files are identified by the "file" command or something that functions more or less similarly (and is part of the GUI desktop environment); those look for "magic numbers" within binary files, make reasonable guesses at text and various programming language source files, and may or may not also know about conventional filename extensions and such. Generically, such things are known as "typing engines". In the long run, I would hope that something better would evolve to solve that particular problem. Just like NTFS can have multiple "streams" of data associated with a single file (and I suppose stuff icons and other useful things in those), one can have "named attributes" under Solaris on UFS or ZFS filesystems. Maybe one day, such functionality will get standardized across Linux and other Unix-like OSs (NFSv4 may help push that a bit?). Those can be used to approximate the NTFS functionality, as well as Mac OS "resource forks". If a standard name for the purpose was chosen, they could also be used to attach a MIME type to a file when it was created. I think that would be ideal, because certainly the app creating the file would "know" what it was better than anything else could guess. The Burroughs (now Unisys) mainframe OS "MCS" (remember Tron?) had a file type attribute ages ago, so this is hardly a new concept. That's IMO the proper way to store that info: out-of-band or as metadata, neither part of the file's name nor part of its regular contents. But that's a long term possibility, not likely to happen in the next year or two. As for installation, as I said, it is possible to set up a single self-extracting executable that works under Unix, complete with install wizard and all. But that sort of thing is frequently not integrated into whatever the particular Unix variant uses for software package management. Remember that most of your Unix gets used in large scale environments; pointy-clicky isn't nearly as important as being able to set up a bazillion systems to all look identical, accounting for the fact that all the software installed is legitimate, etc. Once a repository-based installation system evolves sufficiently, and well-populated and self-consistent repositories are available, I suspect that'll be at least as easy as distributing magical self-installing executables; and probably be safer and more scalable, too. It would probably be more like using a browser than an install wizard though. Looking that much more like Windows for familiarity's sake would mean repeating a lot of Windows dubious design choices. It would also be very difficult if not impossible to look that much like Windows while also looking very much like Linux, and still not breaking all the existing apps that run on Solaris. There are some guides out there to introduce Unix or Linux to Windows users. One example is http://www.yolinux.com/TUTORIALS/unix_for_dos_users.html which just maps DOS commands to Unix equivalents (but note it has a Linux orientation, so some of the details, like the shutdown command, aren't quite the same on Solaris). Maybe if someone viewed making immigrants from Windows more comfortable as an essential outreach, they'd put together such a guide for Solaris users (if it doesn't already exist and just hasn't been publicized enough). I'm just not the one to do it, having little familiarity with Windows, and none with difficulty getting up to speed on yet another OS (of those that are still around, Unix is probably not the hardest to use!). But then I've used various versions of Unix since before there was a Windows, so I'm probably not typical... > Another point I'd like to bring up is the > incompatablity of Windows Applications. > I applored those who are working on the Wine Project, > I cannot tell you If it is any good persoanlly, > because of the 1st point i braught up -i can't > install it! > But none-the-less they are trying to create a > Emulator of sorts. > Why can't OpenSolaris create their own emulator of > windows -- simular to that of Wine's but better and > works on all applications. For example Apple Macs. > They are Unix based Operating systems and they > managed to create an emulator, if it is legal, read > through their code to get an idea of how to make it > work successfully. > If you can bi-pass the whole emulator thing and make > OpenSolaris compatable with Windoes based > applications, that would be even better. I know the > file system is different, but if you can't make > sothing that puts all the files into the normal > folders for OpenSolaris, surely making a folder > purely for the storage of these Windows files would > be easier. (eg. /winapps/program_files/.........) I hope eventually wine will (a) be available by default, and (b) work better. The former isn't up to me, but I think the latter is a reasonable expectation. It will never be perfect, and neither will anything else, because in all probability Microsoft has no interest in making it easier for their competitors to make Windows unnecessary. At one time, Sun had their own thing that was a little like wine, called "wabi". But that pretty much faded out in the Windows 3.x days; wine probably is among the best of its kind right now (i.e. running Windows applications under some other OS, without having a full virtual machine running Windows, about which see below). And wine, or at any rate a derivative, also runs on Mac OS, which probably has more desktop users than Linux and Solaris together (although nowhere near as many as Windows). So there's probably enough critical mass behind wine that getting it readily available and usable on Solaris might be more effective than trying to create some new thing (which didn't work out so well with wabi). One could always run Windows under Xen on Solaris. That would be 100% compatible with all Windows apps (since it would be running Windows in a virtual system). But for those apps that will work with wine, I'd expect the performance to generally be better, as well as offer the ability to set up one-click access with fast startup time. > and my final point for now is the extended desktop. I > made a fuss about this before, but i think that it > could be done. > using the code: > > xrandr --output VGA --left-of LVDS [...] A lot of that stuff is still reasonably new and evolving. I would hope it would eventually get better (although perhaps not much like any one person's expectation of what "better" might look like). X spent a number of years in limbo, being good enough for what it was used for but not having much in the way of support for commodity hardware, readily available fancier input devices, etc. This is getting better, but it'll likely be awhile before it's really caught up. Insofar as most graphics card and input device (data glove, space mouse, brainwave reader, ...) manufacturers will support Windows first and most or only (just because of the sheer volume), it may never catch up 100%. But at least a couple of the major graphics card manufacturers are realizing that they need to provide drivers, or specs, or both for other OSs. So maybe it will continue to get closer. I've heard and read of a fair number of Windows horror stories too. The trick isn't just to pick up the functionality and ease of use, it's also to avoid making some of the same mistakes... This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
