Submitted by SkyOS has received an update to the Viewer application (system file browser). Many changes have been implemented, including a tabbed interface, universal drag-and-drop, and many others. Head on over to the SkyOS website to see a video of the new Viewer features in action. Thanks to the recently implemented Profiler, an interesting system bottleneck has been identified and fixed in SkyOS. This has allowed for increased performance across many functions within SkyOS.
Wow! I am impressed by the fluency of the app! How about a Linux port 🙂
SkyOS is trying very hard to get Linux ports. Some of their bounties are up to €150.
he didn’t mean ports of linux apps to SkyOS (what the bounties are for), he meant a port of the viewer app to linux.
(( I know. I was just trying to bring the discussion back on-topic. ))
Robert should file for patents just like Microsoft and Apple do. That video shows something quite impressive. I haven’t used MacOS 10 much but I’ve never seen in any OS what is shown on the video.
Edited 2007-07-28 09:28
The tab feature is indeed interesting. I remember seeing it a few years ago in a ftp client for Windows that I quickly forgot about (and just about anyone I guess, I can’t remember its name). The fact that you need to click play before previewing a video (or, I assume, even starting to cache it) is also a good feature, as anyone who has opened a folder full of clips on Windows would tell you.
Still, I’m somehow not convinced that’s SkyOS, we all know SkyOS is a hoax, right? [kidding of course]
take a look at these two for windows then:
http://www.cubicreality.com/
http://www.mustangpeak.net/
I see the WinXP Explorer sidebar, KDE icons, and Konqueror-like tabs. So which of these things should be patented by Robert?
Sky Os is really shaping up
I hope we eventually get a build that will run on some piece of hardware I own or virtual environment I run. I want to be impressed too.
touché. I haven’t got a copy my self, and I’m no too worried that they won’t make different builds for different architectures once they finish 1.0
seeing as they are still in beta, it’s pretty impressive.
Quote, from SkyOS FAQ:
Am I the only one not impressed by kernel resident widgets?
Am I the only one not impressed by kernel resident widgets?
Explain yourself?
Putting stuff on kernel space is stupid. Anything thats not core functionality needed to actually run binaries should be implemented outside of the kernel space. Why? Well, for starters there’s no such thing as memory protection in kernel sapce. That means that if something goes wrong, say, a stack overflow, the whole system goes down in flames. That’s why some guy invented the microkernel design: to remove as much stuff as possible form the kernel space so that in the event of something going seriously wrong, the system remain fully operational. Isn’t this approach to OS design you’ve defended time and time again on this forum? So why does anybody need to explain himself to you as to why putting stuff in kernel space is bad?!?!
But that’s not all. The single worst thing anybody can implement on kernel space is the GUI subsystem. Why? Well, because it makes every single GUI interact with the kernel. A poorly programed application with a bad pointer can bring the whole system down, and even a malicious web page can result in privilege escalation. It’s the encyclopedic definition of a bad move. The performance gains obtained from doing such a thing can be matched and even surpassed by a properly designed userspace resided GUI subsystem. Like QNX Photon.
I for one think SkyOS is the new poster child of the proprietary/closed source development model. I’ll just wait for the final version to see how much BSD code this guys are using. No, I don’t think it’s possible for just a bunch of guys to develop something like this. Well, at least not without some outside help or inspiration. Anybody who thinks otherwise is living in the pony-fairy-magic land where every thing is possible and hasn’t got a clue of how hard it is to actually develop software completely from scratch. Not to mention that developing an OS with the features found in SkyOS is probably as hard and time consuming as developing a next generation action game, and that takes a team of 50+ guys laboring over the course of many many years.
I mean, they sure are entitled do rip and use BSD/MIT code or even just check out for inspiration, that’s fine with me… I’d just love they’d cut the crap and admit they’re using it. But i guess that would be admitting that the proprietary development is not as superior as some people claim it is.
Putting stuff on kernel space is stupid.
You don’t have to tell me. I’ve written several articles on microkernels and monolithic kernels, and I’m well aware of the (dis)advantages of each. I simply hate comments that flat out say “Xyz is stupid”, but provide no explanation as to why it is stupid.
The original commenter didn’t do that.
I think it’s fair to assume most of us know a thing or two about OS. After all, this isn’t shinyponies.com :p
The only reason, so far as I can tell, for why people think the GUI shouldn’t be in the kernel is because Unix didn’t put it in the kernel, therefore, it’s wrong to put it in the kernel. All of the reasons you gave above could just as easily apply to any other subsystem, including (especially!) the filesystem, terminal drivers (which reside in the kernel in Linux and are functionally equivalent to having a GUI in the kernel).
The GUI is a shared resource, like files, terminals, memory and CPU. As such, in a properly designed OS, the GUI should be part of the OS, and in a monolithic kernel, it should reside in the kernel. That doesn’t mean all of the GUI is in the kernel. Just the parts that are relevant to sharing the screen and interacting with physical device drivers. Everything else, such as high level window management, GUI widgets, frameworks, etc. should most definitely be in userspace. This is, in fact, how Windows does it and it works really well.
X is moving in that direction kind of, by putting modesetting, DRI/DRM and screen allocation into the kernel DRM driver.
This is exactly how it is done in SkyOS. Only the shared resources like the physical window list, the clip rectangle list, the visible rectangle list as well as parts of the graphic driver are running in kernel mode. (this prevents a lot of task switches when doing drawing operations or talking to the graphic card).
The GUI itself, the widgets, the actual logic and interface are implemented completely in usermode. As a developer or user you never access any (GUI) kernel functionality directly.
@xhemi:
Thanks for the hint, fixed the FAQ section as this was rather irritating.
@n0xx:
Which BSD code are you talking about?
Edited 2007-07-28 15:11
Which BSD code are you talking about?
ehem.. “SkyFS”?
edit: ah, sorry – that’s MIT-licensed code.
Edited 2007-07-28 15:31
ehhem, and what should we admit there (as n0xx requested)?
well, actually I don’t care. just wanted to be part of the religious discussion that takes place everytime skyos is mentioned
on the one hand, I find it funny to ask money for a sequence of 0s and 1s, on the other hand, as a programmer myself I want to be paid for the work. as long as it’s well-documented (which SkyOS is, since it’s still beta) I don’t care.
btw: do you have a release schedule for 5.0 final (esp. the free demo you once promised)? I know such questions are evil, but I want to see it working before spending my hard-earned bucks.
SkyFS is based on OpenBFS. This was never a secret. Robert has given back changes and bug fixes to the Haiku team.
Edited 2007-07-28 15:43
On a related note, do you have any resources you can point me to on writing an efficient clipping system? I’ve been working on something on my own that needs clipping and I’m afraid I’m just not smart enough to figure it out myself.
http://portal.acm.org/citation.cfm?id=274363.274364&coll=GUIDE&dl=G…
The actual interface, required to be human-usable, isn’t core functionality…?
Why in the devils name would a GUI ever be REQUIRED for any OS is beyond me. Even Windows has a native console interface, although Microsoft only let’s you use it when you boot through the Windows 2k/XP installation CD and fire up the recovery console. So no, no GUI should be considered Core functionality because any half decent OS must have a fallback mechanism through wich us techies can fix broken stuff instead of just telling everybody to reinstall.
Well… you can argue and protest all you want,
it’s Robert’s design decision and it won’t change. ^_^
If Skyos is ever recognized to be a stable, robust, fast and reliable os, it will be proof that his decision was a good one.
I don’t think that this day has come yet ^_^,
yet…the way Skyos is improving might already be proof enough, that going the C++ way and putting some stuff in the Kernel was a good choice.
Anyway, personnaly, I think that Robert knows much more about os/kernel design than most of the people that come here, including me, so I just trust him ^_^.
Can’t you trust him a little bit too ?
“Even Windows has a native console interface, although Microsoft only let’s you use it when you boot through the Windows 2k/XP installation CD and fire up the recovery console”
not entirely right…..the thought windows power shell comes to mind.
Because 99% of computer users are NOT techies and do not have the inclination or necessarily even the ability to fart-arse around with consoles and command lines, nor should they ever have to. CLIs are a primitive relict of a bygone age of computing when computers lacked the power to run an intuitive GUI, and while CLIs are still important for some sys-admin functions, as far as the vast majority of computer users are concerned, a GUI is the only way to interact with a computer.
Now, you can argue over the technical merits of this until the cows come home, but the fact is that only a tiny minority of computer users have any desire to go back to the bad old days of using DOS prompts and text consoles.
For most computer users, if something in the OS breaks and they get dumped back to a command line prompt, they will have no more idea what to do than if the computer doesn’t boot at all, and will either A) just re-install the OS (less likely for most users) or B) take it to someone who knows what they are doing and can use some recovery tools to rescue a broken OS if possible (most likely scenario). And this is assuming some permanent breakage – it is far more likely that in the event of a GUI based OS having a serious error that a simple restart will fix it.
A GUI is the most sensible way to interact with the OS for the majority of users, as it uses the same parts of the brain we use to interact with the physical world and is hence fairly intuitive once you grasp the basic metaphors involved, whereas command lines require the user to adopt a special mode of thinking that most people find difficult, and is a highly abstract way of interacting with a computer. Many computer experts fail to realise that what comes easily to them is totally alien and incomprehensible to most “normal” people.
So, as far as I am concerned, Robert is entirely correct to require a GUI as the primary means of interacting with the operating system, and putting it in the kernel space is fine, since if the GUI breaks, the user would likely restart anyway. This is not intended as a server OS, where restarting the computer could be very disruptive. If it crashes or becomes unstable, you restart it, just like most Windows users do. And as a desktop OS, there would be little need to use a remote connection to control the computer via SSH or whatever, so a command line is largely redundant for most users and tasks.
Because 99% of computer users are NOT techies and do not have the inclination or necessarily even the ability to fart-arse around with consoles and command lines, nor should they ever have to. CLIs are a primitive relict of a bygone age of computing when computers lacked the power to run an intuitive GUI, and while CLIs are still important for some sys-admin functions, as far as the vast majority of computer users are concerned, a GUI is the only way to interact with a computer.
Now, you can argue over the technical merits of this until the cows come home, but the fact is that only a tiny minority of computer users have any desire to go back to the bad old days of using DOS prompts and text consoles.
This is a matter of vision in the end, but it’s been highly fueled by a huge misconception. Every person I’ve met that passionately thinks GUIs are the Only Way also believes that the ultimate standard in terms of command line is command.com or cmd.exe
Get over it. Both *are* relics from CP/M. Microsoft never bothered to do anything serious about them from the days they were running on computers with 64 KB of memory. Compared even to small shells, like ash, cmd.exe seems to have suffered a full frontal lobotomy.
I’m not (and nobody is) saying that there should be no GUI whatsoever, simply that there are cases when a GUI is not the best to handle things. Try to use a GUI for a quick task like compressing all the MP3 files on your hdd which are larger than 7 MB and you’ll quickly understand where’s the problem with GUIs and why a strong CLI is required.
The main argument here is actually including the GUI in the kernel, and I agree that’s stupid. The idea of “when it locks down, restart it” is the key to a very flawed design. Is the GUI essential to running the OS? Can the OS boot without it? Is the GUI tied to any kernelspace services that are not accessible otherwise? If the answer to all these three is no, then there’s no room for the GUI in the kernel.
“Try to use a GUI for a quick task like compressing all the MP3 files on your hdd which are larger than 7 MB and you’ll quickly understand where’s the problem with GUIs and why a strong CLI is required.”
bad example on your part maybe?
Search for mp3
Sort by size
Drag mouse over them
right click, add to zip
Done.
I’m pretty sure I can do this much faster in a GUI than I can in a cmd.
Edited 2007-07-29 17:49
> The main argument here is actually including the GUI in the kernel, and
> I agree that’s stupid. The idea of “when it locks down, restart it” is the
> key to a very flawed design.
And what are you suggesting to do else when the GUI locks down, other than restart it? Of course, best would be if the GUI didn’t crash at all, but then it doesn’t matter whether it is in the kernel or not.
> Is the GUI essential to running the OS?
In modern desktop (not server) OSes, yes. Just as the command-line interface was essential in earlier times. It is the one and only user interface through which the user interacts with the system.
May I also add that being essential should not have an impact on whether the GUI runs in kernel mode. Both process management and a file browser can be regarded essential, but only the former runs in kernel mode.
> Can the OS boot without it?
No, since then there wouldn’t be any way to interact with the system.
> Is the GUI tied to any kernelspace services that are not accessible otherwise?
Yes: access to the hardware. At least some part of the underlying renderer must interact with the actual graphics hardware, and that requires kernel-mode privileges, which imply that a bug could hose your system.
There are a number of GUI utilities that make this sort of batch file processing a doddle, and much more intuitively and quickly for a normal user than even the most sophisticated command line. Not that many people would actually want to do the task you described (you could probably have picked a more realistic example of batch file processing).
If you have an OS that puts the GUI in userspace, and the GUI crashes, leaving you with a command line, what exactly do you expect the average CLI illiterate user to do? This is one of the things that still causes people to baulk at using Linux – if the X server crashes, most people will have no idea what to do from the command line. They will probably just reboot the machine or go back to using Windows. They are probably not even going to try typing something like “startx”, simple as it may seem to an experienced and technically minded computer user.
It is not flawed design at all to make the primary means of interacting with the computer an essential kernel space service, unless you are talking about a server OS, which is quite different to a desktop OS. On the contrary, it is very good design.
For most users, the GUI is as essential to the operation of the computer as the thread scheduler or the file system, because they cannot do anything without it.
There is no argument at all for keeping the GUI out of the kernel for a desktop OS where the computer is essentially useless without a GUI to most users.
Caveat: if you are going to keep the GUI out of the kernel space, the sensible option is for the OS to automatically restart the GUI if it stops for some reason, so that the user is not presented with the horror of a blinking command prompt on an otherwise blank screen.
Anyone remember that wonderful Ubuntu update bug where it borked Xorg? That was a classic example of where not having a GUI is the same as not having an OS at all for the average end user. If you don’t know how to use the command line to repair Xorg, and you only have one computer and all you get is a command line, you can’t exactly browse the forums to get help – you might as well just reinstall the OS (the average user is unlikely to know there are browsers that run from the CLI).
The thing that surprised me the most about that post was the comment that “any half decent OS must have a fallback mechanism through wich us techies can fix broken stuff”.
Is it so impossible that the fallback mechanism could also use a GUI? Windows in Safe Mode is pretty much what he’s talking about…
“Is it so impossible that the fallback mechanism could also use a GUI?”
No, it’s perfectly possible. Of course, it depends on what you mean by GUI. Is the Linux framebuffer console a GUI? It doesn’t use a text video mode but it’s interface is “textbased”
Also, BeOS didnt have a console fallback and it worked just fine.
What’s the real difference between a command-line interface and a GUI anyways? They both require the OS to present some sort of screen-based interface to the user. Whether it is pure text, or graphics is just a question of additional features. Input/output must still be multiplexed somehow and separated on a process by process basis. If the OS enforces access control and permissions on files, terminals, memory and CPU, why should it also not enforce access control and permissions on the shared resource that is the screen?
A well-designed GUI presents a limited list of descriptively labeled relevant options (menus and buttons) whereas a CLI requires the user to know commands from memory. A GUI can use metaphors from real life, such as folders and arrows and pictures, whereas a CLI is just a blinking cursor. GUIs are a familiar concept to many users from machines in daily life such as ATMs and cell phones; CLIs are alien to most people. GUIs are for people who need ease of use rather than unlimited power, which is most people.
I mean, they sure are entitled do rip and use BSD/MIT code or even just check out for inspiration, that’s fine with me… I’d just love they’d cut the crap and admit they’re using it. But i guess that would be admitting that the proprietary development is not as superior as some people claim it is.
Do you have proof for this? And Robert has never claimed proprietary development was superior, it was just his choice to make SkyOS proprietary. If you don’t like it, don’t use it.
SkyOs is going to go really far.Keep up the good work.Waiting for it to release.
When I go to check out the video, I get a system-is-down message; when I go to the base page, I get a default ad page.
That’s the one thing I don’t like about SkyOS as a company; their operating system is great but the third-party software they use for their webpages isn’t so great. :/
Perhaps they use fasthosts. The link is up now, and it was up this morning as well.
We moved the server a few weeks ago to prevent especially this problems.
Do you mind telling me which error message you got? From plesk, drupal, apache, etc… ? The server logs don’t show any problems or dropped connection requests.
Something to do with Plesk.
check my post above yours
remove any skyos.org entries in your hosts file
if you’re getting a plesk page instead of the skyos website, you probably still have the old server IP in your hosts file (as a fix for the dns issue we used to have).
Site has worked fine here all day.
screw off vista. welcome skyos!
I think SkyOS has a chance at becoming a disruptive technology.
That is a very slick and intuitive File Browser.
I’m picking my jaw up off of the floor right now.
Not even file browser in Windows Vista has the level of functionality that I see here.
Simply amazing.
Well fantastic, that is the reaction we were hoping to achieve.
So nice with the tabs, better than many windows or jumping around in trees, well done and nice to see that there are some innovative developers out there aswell (not just people copying whatever microsoft or apple do..)
shame it is not open source
wow somebody modded me down, so again shame it is not open source