Please create an account to participate in the Slashdot moderation system


Forgot your password?
User Journal

Journal Journal: Star Trek : TNNG , let the debate begin! 1

This has been thrown around occasionaly on slashdot in the past and here's my fleshing out of the idea.

- first, start pre production soonish but hold off a few years, bring it out on the 25th anniversary of TNG.

- second, give them a decent ship that looks mean and doesnt have a barber shop onboard. preferably something akin to the sleek and fast-as-a-bastard Exelsior class

- third, show some of the dark side of the federation, TNG and DS9 occasionally allowed us a peek into dimly lit bars, spaceports and mercenary cargo ships, sure you don't need to go all the way to firefly extremes, we want it to be trek afterall

- fourth, give them a proper mission, or three over the course of the series' run, sure have monster-of-the-week episodes to get people interested but also expand on the DS9 theory of an overall plot (but at least decide in the first place what it is).

- finally, install a now older, wiser, and not at all anoying: Captain Wesley Crusher

Here's how i see it playing out in my geek brain, it just needs a few, er, important blanks filling in. the first half of the double-length pilot will see a retiring admiral picard meet up with Crusher at his ben kenobe style hut on some rocky planet somewhere. For $REASON (to do with his experiences gained whilst off with The Traveller perhaps?) starfleet have sent picard to get Crusher on board for $MISSION. They go off somewhere and get stuck up a mountain and after a reversal of fortune on TNG's "Final Mission" with picard helping him out crusher realises he now owes the old boy a favour. so he agrees to go along back to starfleet to check it out. Picard cheekily flies by the shiney new ship to bait Crusher along. and after having dinner with his mum, probably, Crusher takes on the job under certain conditions, especially that he wants a couple of his own guys on the crew (who specialise in Tactical and $SOMETHINGELSE), but not in a Maquis-on-Voyager-oh-dont-we-all-get-along-nicely-after-all way, more like Garak-and-Odo-on-Defiant way, not in uniform, not technically starfleet but under Crusher's command nontheless. For the hell of it you could throw in a bunch of rowdy often drunk klingons, instead of bloody vulcans. Crusher, being a kick ass pilot and engineering wizz will also not be entirely liked by the crew: the sexy assed Youngish ensign girl who he keeps supplanting so he can steer the ship himself (though they end up finally getting it on eventually, probably), his first officer, who's pissed that this guy just got handed a captaincy and he was overlooked despite years of butt licking and the Chief Engineer, because crusher's not only always interfering but also crashing into things.

Set them off on their $Mission, and let battle commence!


Journal Journal: "secret amazon logging revealed"

...was the title of a news story on bbc cefax's sci/tech pages at the weekend, but i didnt catch it at first so waited 5 minutes for it to come aroung, only to find out that it was about people cutting trees down in brazil.

User Journal

Journal Journal: a true database driven file system

all files given unique id (local to system). could be based on time file was first created in milliseconds or a counter that starts from a random offset (so that os files arent in predictable locations)

database layout:

file_id = unique id, used by all filesystem operations, shortcuts and link tables
name = name
description = long description
type = type: e.g. "audio/mp3" (this replaces the file extension)
meta = descriptor: audio
flags = read/write/drm etc
binary = the file's binary data
->depends = link table of files that this file needs
->dependant = link table of files that need this file

files in this system no longer have a physical location, they can be mapped to by any means. different users could "see" the filesystem any way they wish:

the windows "my documents" folder would not be a folder but a query or link table, the technicalities of this hidden from the casual user.

mp3 files could be listed by artist, genre, decade etc. and playlists could simply be link tables. all of these could be represented in the GUI much like standard folders are now: a user creates a "folder" and drag-drops files into it to create "shortcuts" to the original. the database spec itself would be internally extensible, mp3 files can have artist,title,albumn,mix,length,bpm,etc set but a track appearing on an albumn and a compilation would need duplicate entries, forcing a fully relational setup. indeed mp3 files would no longer have one name to refer by no more "jimi_hendrix_experience_are_you_experienced_track_01.mp3"!

a linux config file could be simultaneously found in //etc/config and //programs/myprogram/config for example, different runlevel configs could also be seperated this way. uninstalling a program would involve removing all it's dependancies (tracked via a link table); if a dll file has no dependant links, then it is safe for deletion. if a program attempts to install a dll file that is identical to one on the system a copy is not made, only the links are updated, the program installer need not know if this has happened.

seamless network integration, if my brother's pc has a bunch of mp3 files on it and we're on the same network our mp3 lists and queries would appear as one, good gui design would show the distinction between local and external files (e.g. different color) and options to create a local copy would appear under the context/right-click menu. with (buildable) options for getting all-by-artist all-by-album all-in-this-or-that-playlist etc. files that are identical but exist on both could be shown normally or have another color, user definable!

once we get away from the rigidist tree-and-leaf thinking of filesystem and network layout then there's a lot that we can do (and not just sort our mp3s and holiday photos)
Operating Systems

Journal Journal: Suggested new OS FS permissions/security model 1

Being a web developer I'm used to having my sites live in virtual server directories. The basic permissions of which are set by the administrator (read/write/execute) etc. But the fundamental restriction in place by default is one where i cannot write or modify a file anywhere above my virtual root directory. regardless of it's physical location on the server.

this imposed glass ceiling could be stretched to program permissions across an OS. Imagine a mail client called Origami Email (OE) (c:\programs\oe) that had a vulnerability exploited by a malicious email. the best the incoming worm could hope to achieve is the modification of the files in the directory it resides (c:\programs\oe\emails) or any sub directories (c:\programs\oe\emails\archive) but not it's parent or an adjoining branch. i.e. the OS core and other programs would be wholly inaccessible to it. all that needs to be done is to have the file system know where the code accessing it originates and act accordingly.

Issues are now raised when it comes to usability, if PhotoEdit lives in c:\programs\photoedit it wont be able to get to c:\documents to open or save photos! So the default permissions would set c:\documents to a DMZ (enabling aforementioned worm to stomp all over it if it wished, obviously) and applications could have run-time set permissions much like web certificates, "always allow" "this time only" etc. so a more secure setup would allow PhotoEdit full access to c:\documents but only after the user first tried to use it and clicked "always allow".

Allowing any executable access to the whole file system upon a simple request is an outdated methodology. OS's should instead move away from hacked together "system folder" traps and towards a more "top down" approach. This is also simpler than a firewall type approach to FS tech as the OS root is fundamentally protected "out of the box" by being on a different branch of the FS tree. And a mounted virtual directory approach could also be included, the net could be easily firewalled by having the tcp/ip stack a root mount (c:\tcpip) with programs reading and writing to it as they would a file (c:\tcpip\http\\

It doesnt take too much imagination to then extend this approach into ram, where programs reside and what address space they can influence should directly mirror their position in the FS. Therefore also removing the ability for malicious programs to subvert the FS protection by jumpimg address space into a region with full FS write/execute permission

Slashdot Top Deals

Never call a man a fool. Borrow from him.