also a torrent has been made available at the same location.
get_iplayer has been removed because it encourages people to download copyrighted material. i'm interested in ensuring that implementations of RTMP and understanding of this protocol are available.
I think a cruise missile would be more appropriate or maybe a few precision guided weapons applied as needed. The source of such an attack is a legitimate target and sending a message that such targets well be dealt with in a manner proportionate to the damage they inflict makes a lot of sense to me. If the attack is state sponsored, retaliation that is far out of proportion is called for since the attack constitutes an act of war.
not being funny or anything, but you _really_ haven't thought that through.
1) "since the attack constitutes an act of war", if you actually CALL it war, it's a DECLARATION of war, and then the people you are attacking (with the cruise missiles) are allowed, under international law, to retaliate, including killing any citizens of the country that made the declaration.
so, by making it into "a war", you've just "excused" the deaths of the very people who ended up being killed [at the airport, or whatever]
2) typically, internet attacks are made by teams of people who will be coordinating using distributed infrastructure and will be in totally different physical locations.
attacking one single location serves absolutely no purpose other than to piss off not only the rest of the people in the cyber team but also the host nation.... you didn't think that the attackers were actually in their own country, did you? they'll be holed up in areas where the collateral damage would be immense, in a NEUTRAL country.
unfortunately for these idiots who want to declare cyber attacks as an "act of war", the implications are that that means it _becomes_ a declaration of war.
and when you do that, it's a whole new ballgame.
not least is the fact that when you declare war on a citizen of a country, that citizen has the right - the RIGHT - to attack and kill any citizens of the country that has declared war.
by making this "a war", the united states government can expect these "cyber criminals" to have some serious weaponry to hand, and, importantly, if the united states army, police or even ordinary united states citizens turn up on the doorstep of the "crimminnall" and the "crimmminnalll" kills them, the "crimmminnalll" can claim, "well, the united states declared war on me, what do you expect??"
and they will be allowed to walk away, having killed everyone that was sent to stop them, because, under international law, that's what you're allowed to do, in war.
so i don't think the united states government has really thought this one through. if it's left as a "crime", then they can be tried for "crimes".
but if they try to treat them as "war criminals", then that's _actual_ war, and they're absolutely entitled, under international law, to defend themselves and kill anyone that tries to attack them.
my first linux install was slackware 3.1 in about 1995, as i needed linux in order to make the improvements to samba that i could see it so desperately needed. at the time, there was no integration with the network neighbourhood, so that's what i started on - nmbd.
i walked in to the computer room at cambridge university. various students kindly held the door open for me so that i could get in. i sat down at one of the machines, pressed alt-f1 (as advised) and was able to use the command-prompt to do a wget and then a "dd" copy of the floppy disk images.
ironically, the cambridge university connection was 350k/sec (in 1995!!!) and was far faster than the speed of copying to floppy disk.
i got the first twelve or so "basic" disks, and soon discovered that i needed x-windows, the gcc compiler, and much more.
i accidentally missed out one of the x-windows disks, but it seemed not to matter.
by the time i was done i had bought or recycled 75 floppies, and had had to return five or six times to the lab, each time some kind student held the door open and let me in.
there was no way i could have installed that lot over the internet - even the local cybercafe only had a 26kbaud modem.
in the end i got what i needed - the gcc compiler, x-windows and enough to get samba compiled so that i could start tinkering with it.
slackware seemed like a good idea at the time, as i simply didn't know any better. it was only later, when internet connections became much better, that i got - and have stuck with - debian.
unfortunately, people will see music, available for download, and go "oh, this must be music that i would have to pay an extortionate sum for. i'm not doing that".
in other words, they *think* it's a multi-mega-corporation-backed rip-off when in fact it's nothing of the sort, and the rippers don't care about making a distinction between the indie bands' rip-off and the multi-mega-backed rip-off, so the downloaders aren't being informed.
The experimental combination of the Python-to-Javascript compiler, http://pyjs.org/ and the Python Bindings to Google's V8 Engine, http://code.google.com/p/pyv8 brings a ten times performance increase over standard python, already.
not - "10% now and 5x in the future" - that's a 1000% increase NOW.
When V8 supports the ECMAScript "Harmony" standard, which will include support for basic integer types, then there will be "correct" support in the PyJS + PyV8 combination for numerical types, and the word "experimental" can be dropped.
http://pyjsorg/ also includes an experiment showing the bindings of the PyJS compiler with the Python-Spidermonkey project. The spidermonkey JS engine has the advantage of running on generic platforms instead of just ARM and 32-bit x86 platforms, but has the disadvantage of being slightly slower.
Javascript is a _really_ interesting language that makes it in many ways highly suitable as an intermediate compiler language for compiling dynamic languages as Ruby and Python.
there is a lost art involving inter-program communication which has not really been kept up-to-date as the complexity of applications and users' expectations both increase.
the "simple" principle which you are referring to - of joining (pipelining) applications together to achieve a purpose - was the ethos behind unix that made it so successful.
but - that principle was based on text files.
along came windows and blew that out-of-the water - but not in ways that you might anticipate. what really blew everything away was the use of MSRPC aka DCE/RPC with some small but highly strategic enhancements.
the use of MSRPC in Windows NT took the inter-process communication principle to unprecedented (as far as users were concerned) levels of transparent program boundaries.
the basis of DCE/RPC is that instead of burdening the developer with "rolling their own inter-program file communication", the developer can instead subdivide the application at the API level.
this was so successfully deployed in Windows NT that nobody really even knows that it exists. even the _internal_ teams inside microsoft often assume that an API is "direct" instead of networked, resulting in 2nd level APIs that repeatedly send 10mb of unintialised _crap_ over-the-wire.
then, later on, once the proprietary push of DCOM onto the world failed, microsoft tried again with CLR. CLR has been slightly more successful, as it is not tied historically to the operating system.
the bottom line is that there is plenty of technology out there for cross-application communication that makes it perfectly possible to have really quite sophisticated applications written in different languages.
DCOM. DCE/RPC. JSONrpc. Objective-C. CLR/.NET. even CORBA, god help us.
all of these have varying degrees of sophistication _well_ beyond "pipes and text file formats" that have developers throwing up their arms either in horror or to scratch their heads.
and it's exactly the ignorance and the lack of appreciation for these powerful technologies that leaves you, cthonicdaemon, in the situation that you are presently in.
Do you see the Web-Browser-As-OS implemented as a virtual machine capable of running inside another operating system?
hopefully not - or if it is, i'd hope that it would be more along the lines of an "assisted" VM - you know, making use of those vmx or svm flags on modern processors. so - more like XEN and KVM than an "abstract" virtual machine.
what would be really out-of-order would be to use a java or a CLR (.net) virtual machine architecture. an actual operating system running on top of those would be a complete disaster.
you'd think, wouldn't you, though, that it would be possible to do a decently-designed browser, with pages running as separate applications, that all properly coordinated and ran as part of an existing OS, though?:)
Stick a full VM into the browser. Problem solved. Except of course for the huge resources needed to view even the simplest of pages.
The entire push over the last few years to transferring processing load back onto the client is the wrong direction in my opinion, and the browser should remain a THIN client like the original intent. Keeping it a thin client by nature would be secure.
noooo, nonono can do - yes it would be secure, but times have changed _drastically_. what's happened is that as the desktop wars got ridiculous (and i don't just mean between different OSes, i also mean between win95, xp and up), people simply moved to the browser itself to provide access to applications. all the talk of "ubiquitous computing" has actually _happened_.
and, as the expectations of web infrastructure got ever greater, that origial "thin client" architecture began to look... well... thin! so along came flash, and javascript, and god help us java, and then AJAX, and then GWT and Pyjamas which _really_ make it clear that the browser really _is_ just another "widget set" like Python-QT4, Python-GTK2 or Java Swing, and somewhere rather unfortunately along the line silverlight got added to the mix.
and once you're down this road, there really is no turning back. you're now running complex comprehensive applications such as gmail.com, google apps and WebOS and i do _mean_ applications side-by-side in the same "space" and it's just getting too much for the poor little browsers, which were never designed to act as "operating systems".
so i think what we're seeing here is the recognition of the fact that browsers have to become what OSes were designed to do, because browsers are now taking over from what OSes were _supposed_ to be doing, because everyone's moving inexorably to online interaction, now, instead of "isolated desktop".
so is anyone _really_ surprised that the solutions proposed are to use tried-and-tested proven technology, just moving it to where the focus has gone? current browser technology can be compared to OS technology of the Windows 1.0, GEM/DOS and early Mac era!
i always wanted to write my own desktop, like webos or the example/demo that comes with extjs, using browser-based technology. then i can throw away all the silly desktops i never liked anyway, and run all my applications from inside the web browser. and, because i know that the browser technology is actually an OS, i know it's secure and also will have process-separation so that one app crashing won't take out my entire quotes browser quotes. hooray!
no see my earlier posting on this subject: the use of Security Descriptors and potential checking against the PDC is what makes process creation expensive, which then makes _thread_ creation so cheap in NT, by comparison.... you can't really secure threads from each other, so why bother, basically, was the general attitude that can clearly be seen to have been taken.
short answer: the ACL-based security model, which is transparently networked onto "NT Domain Security".
the design comprises:
* the evaluation of the security descriptor, which is a binary blob that needs to be decoded
* the creation of a process, where the parent has a security descriptor "inheritance" chain to its parent, to its parent etc. etc.
* the possibility for evaluating an individual ACE that could be on a remote machine (a PDC)
* just the _possibility_ of having to contact the remote machine (the PDC) leaves a design where the creation even of a local process requires the use of MSRPC (on "local rpc" pipes - ncalrpc) in order to not drastically overcomplicate the code any more than it already is.
goodness knows what else is going on, but it's very very powerful but unfortunately with that power and flexibility of design comes a whopping great overhead.
and no you can't cache the results very much because someone might revoke a user's right to CREATE_PROCESS and they'd get a bit unhappy about that not being obeyed.
why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop
I could see a case for it. I could also see a case for doing it WITHOUT modifying the full range of OS technology. Why is it so hard to see that a secure browser could be done using existing operating systems?
sorry, i assumed it would be clear. applications running within the browser are becoming more like _real_ applications - _real_ "desktop" applications, especially with downloadable-executable-code ( "plugins" such as as adobe ) having been thrown into the mix.
and you have multiple of "applications" running simultaneously.
therefore, you have security implications, application stability implications, and much more [i recently had firefox crash out-of-memory on linux, and i have 2gb of ram and 3gb of swap space].
therefore, you need to start looking at isolating the applications from each other, whilst also allowing them access across a common API to a central set of protected resources (screen, keyboard, mouse, other devices, memory, networking), to be able to communicate across that boundary without impacting any other applications or the central resource management layer itself.
and i think you'll find that if you look closely, that's pretty much the definition of an OS.
so, working from the requirements - the expectation that good, hostile, rogue or simply badly designed applications all need to be given a chance to run, you arrive naturally at the rather unfortunately-logical conclusion that the only decent way to fulfil the requirements is with an actual full-blown operating system.
to believe that anything else can fulfil the requirements, to provide multi-tasked application stability and security, really is sheer delusion, or is... like... expecting a 1980s apple mac OS with a 68000 CPU and no Virtual Memory support, to be "secure".... actually, there _is_ one other possibility: Security-Enhanced Linux (specifically, the FLASK security model behind SE/Linux). and we know what people think of _that_, despite SE/Linux being incredibly good at its job.
i've done event-driven vehicle simulators; i've clean-room network-reverse-engineered MSRPC and NT domains protocols; i've ported freedce to win32; i've added glib bindings to webkit and on top of that, ported a port of GWT to python even _more_ into python by adding DOM manipulation to pywebkitgtk.
in amongst all that mindless drivel of alphabet soup you should be getting a pretty clear picture that i'm not a stranger to complexity.
i've learned that if someone says "surely it doesn't have to be as complicated as all that", it's time to run like stink as fast as possible, out of the conversation and the room, and never look back.
browsers are effectively desktop technology within a desktop (and damn good at displaying widgets), except you're letting the web site dictate what "programs" are allowed to be "run" on your desktop^H^H^H^H^H^H^Hbrowser.
browsers are no longer "just HTML displayers", they are actually executing applications - _real_ applications - that in many instances happen to be written in javascript. GWT, Pyjamas and RubyJS should all hammer that point home.
with that in mind, why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop^H^H^H^H^H^H^H^Hbrowser technology?
Does it really matter if the algorithm is found to be flawed later on, if most of these packages support algorithms known to be flawed today?
does it matter? does it matter?? fuck me it fucking matters.
example 1
there's a type of encryption algorithm principle - the feistel cipher - see http://en.wikipedia.org/wiki/Feistel_cipher - where you perform one simple transform function as "round 1", then for rounds 2 and 3 you do a one-way hash function, and then for round 4 you do a simple transform function.
if the one-way has is ever broken, your encryption cipher is also broken.
game over: any traffic that's ever been using that cipher can be decrypted.
example 2
your credit cards you carry around? the PIN number isn't stored on the card - but an MD5 hash of the PIN number *is* stored on the card (making replay attacks possible, believe it or not).
if MD5 is ever cracked...
game over: anyone can get your PIN number.
example 3
your peer-to-peer filesystem, your git source control system, they use one-way hashes to store an index of the data blocks. let's say that someone deliberately wants to break deployed systems, they work out what file chunks could end up being mapped to the same one-way hash...
game over: anyone can corrupt the database or the peer-to-peer filesystem by _deliberately_ making file or file chunks write to the same block.
i could go on with the list of examples - authentication systems that would fall over; internet bank systems that could be broken in to - we _totally_ rely on one-way hashes working correctly.
it's important beyond _belief_ that these one-way hash functions work, so much so that i was staggered that the question even had to be asked as part of the article-announcement.
"She's just a low-level drone who is only source of information..."
now, children: please, allow me to correct you in case some grammar nazi (other than myself) comes along and rebukes everything you say, on the basis that poor spelling must indicate poor attention to detail and poor ability to reason. like.
the word you are looking for is "whose". "who's" is, as you know, a contraction of "who is".
as an anal attentative grammar nazi and long-time linux supporter and free software advocate, it would be much better that i get to you first before that teacher, or any of her "slazhdot-readin suhporturs" do.
the best way to think of all these smartphones is as a combined phone + laptop on one circuit board, where they're even connected together using USB.
so what these embedded OSes do is quite literally nothing other than send "AT" modem commands (and sometimes a bit more, using escape sequencing) to the on-board modem chipset.
so, unless you start hacking the firmware of the on-board modem, you will still remain within the FCC regulations.
however, some of the cheaper smartphones - in particular the ones based on the TI OMAP series - run a dual-core processor - a TI ARM core plus a TI DSP core - typically a 200mhz one (because lower than 200mhz is utterly useless for smartphone features. but hey, it's cheap).
these phones _are_ a serious risk, because the two CPUs share memory (!) and you can reprogram the registers etc. etc. you can look up exactly how to do it.
anyway, the point is: the radio modem firmware is downloaded _directly_ to the processor, where all of the signal baseband processing is done. things like the GSM signal-strength of the radio can be manipulated DIRECTLY by changing a memory location, using the ARM cpu.
or worse.
clearly, this is bad.
however, the design of the more expensive HTC-designed phones - typically involves a _much_ better setup - with "standard" 400 to 600mhz ARM cpus and a completely isolated "standard" chipset.
the price of the G1 is indicative that it is one of these better setups.
if you want more info, here's where you're going to get it - from the xda-developers and the #htc-linux irc channel on freenode.net. DO NOT waste the developers time on #htc-linux - they are NOT paid to work on the reverse-engineering of HTC phones, but have stuck diligently to the task for over four years, nearly five now, to bring _proper_ community-driven support for linux to these hand-held smartphones.
as people do reverse-engineering and/or find out other information (such as take the backs off and photograph the chipsets) you'll find the info listed, there.
i've just heard back from the developers - it's not in the slightest bit a dead or dormant project. the developers are university students. busy and unpaid ones.
Imagine a true peer-to-peer Web built on something like this.
Imagine, for instance, posting blog or wiki posts as little paragraphs of text, each as a separate file, not uploaded to a 'server' but just put out onto the grid. Cache every chunk of data as it moves through servers, maybe have a name-resolution layer like DNS over the top so that one server is 'authoritative' for your blog posts, but that server doesn't need to be online all the time as long as another one has replicated the data. Add a language which allows transclusion of chunks and/or functional manipulation of them, so you don't have to use messy AJAX tricks which bust the caches.
We could get a few steps closer toward Xanadu.
hey, can you ghost-write my next article on this subject, for me?:)
Slashdot Mirror
http://lkcl.net/rtmp
torrent also available.
a copy of rtmpdump 1.6 is available here:
http://lkcl.net/rtmp
also a torrent has been made available at the same location.
get_iplayer has been removed because it encourages people to download copyrighted material. i'm interested in ensuring that implementations of RTMP and understanding of this protocol are available.
I think a cruise missile would be more appropriate or maybe a few precision guided weapons applied as needed. The source of such an attack is a legitimate target and sending a message that such targets well be dealt with in a manner proportionate to the damage they inflict makes a lot of sense to me. If the attack is state sponsored, retaliation that is far out of proportion is called for since the attack constitutes an act of war.
not being funny or anything, but you _really_ haven't thought that through.
1) "since the attack constitutes an act of war", if you actually CALL it war, it's a DECLARATION of war, and then the people you are attacking (with the cruise missiles) are allowed, under international law, to retaliate, including killing any citizens of the country that made the declaration.
so, by making it into "a war", you've just "excused" the deaths of the very people who ended up being killed [at the airport, or whatever]
2) typically, internet attacks are made by teams of people who will be coordinating using distributed infrastructure and will be in totally different physical locations.
attacking one single location serves absolutely no purpose other than to piss off not only the rest of the people in the cyber team but also the host nation. ... you didn't think that the attackers were actually in their own country, did you? they'll be holed up in areas where the collateral damage would be immense, in a NEUTRAL country.
think about that for a minute.
unfortunately for these idiots who want to declare cyber attacks as an "act of war", the implications are that that means it _becomes_ a declaration of war.
and when you do that, it's a whole new ballgame.
not least is the fact that when you declare war on a citizen of a country, that citizen has the right - the RIGHT - to attack and kill any citizens of the country that has declared war.
by making this "a war", the united states government can expect these "cyber criminals" to have some serious weaponry to hand, and, importantly, if the united states army, police or even ordinary united states citizens turn up on the doorstep of the "crimminnall" and the "crimmminnalll" kills them, the "crimmminnalll" can claim, "well, the united states declared war on me, what do you expect??"
and they will be allowed to walk away, having killed everyone that was sent to stop them, because, under international law, that's what you're allowed to do, in war.
so i don't think the united states government has really thought this one through. if it's left as a "crime", then they can be tried for "crimes".
but if they try to treat them as "war criminals", then that's _actual_ war, and they're absolutely entitled, under international law, to defend themselves and kill anyone that tries to attack them.
my first linux install was slackware 3.1 in about 1995, as i needed linux in order to make the improvements to samba that i could see it so desperately needed. at the time, there was no integration with the network neighbourhood, so that's what i started on - nmbd.
i walked in to the computer room at cambridge university. various students kindly held the door open for me so that i could get in. i sat down at one of the machines, pressed alt-f1 (as advised) and was able to use the command-prompt to do a wget and then a "dd" copy of the floppy disk images.
ironically, the cambridge university connection was 350k/sec (in 1995!!!) and was far faster than the speed of copying to floppy disk.
i got the first twelve or so "basic" disks, and soon discovered that i needed x-windows, the gcc compiler, and much more.
i accidentally missed out one of the x-windows disks, but it seemed not to matter.
by the time i was done i had bought or recycled 75 floppies, and had had to return five or six times to the lab, each time some kind student held the door open and let me in.
there was no way i could have installed that lot over the internet - even the local cybercafe only had a 26kbaud modem.
in the end i got what i needed - the gcc compiler, x-windows and enough to get samba compiled so that i could start tinkering with it.
slackware seemed like a good idea at the time, as i simply didn't know any better. it was only later, when internet connections became much better, that i got - and have stuck with - debian.
unfortunately, people will see music, available for download, and go "oh, this must be music that i would have to pay an extortionate sum for. i'm not doing that".
in other words, they *think* it's a multi-mega-corporation-backed rip-off when in fact it's nothing of the sort, and the rippers don't care about making a distinction between the indie bands' rip-off and the multi-mega-backed rip-off, so the downloaders aren't being informed.
The experimental combination of the Python-to-Javascript compiler, http://pyjs.org/ and the Python Bindings to Google's V8 Engine, http://code.google.com/p/pyv8 brings a ten times performance increase over standard python, already.
not - "10% now and 5x in the future" - that's a 1000% increase NOW.
When V8 supports the ECMAScript "Harmony" standard, which will include support for basic integer types, then there will be "correct" support in the PyJS + PyV8 combination for numerical types, and the word "experimental" can be dropped.
http://pyjsorg/ also includes an experiment showing the bindings of the PyJS compiler with the Python-Spidermonkey project. The spidermonkey JS engine has the advantage of running on generic platforms instead of just ARM and 32-bit x86 platforms, but has the disadvantage of being slightly slower.
Javascript is a _really_ interesting language that makes it in many ways highly suitable as an intermediate compiler language for compiling dynamic languages as Ruby and Python.
there is a lost art involving inter-program communication which has not really been kept up-to-date as the complexity of applications and users' expectations both increase.
the "simple" principle which you are referring to - of joining (pipelining) applications together to achieve a purpose - was the ethos behind unix that made it so successful.
but - that principle was based on text files.
along came windows and blew that out-of-the water - but not in ways that you might anticipate. what really blew everything away was the use of MSRPC aka DCE/RPC with some small but highly strategic enhancements.
the use of MSRPC in Windows NT took the inter-process communication principle to unprecedented (as far as users were concerned) levels of transparent program boundaries.
the basis of DCE/RPC is that instead of burdening the developer with "rolling their own inter-program file communication", the developer can instead subdivide the application at the API level.
this was so successfully deployed in Windows NT that nobody really even knows that it exists. even the _internal_ teams inside microsoft often assume that an API is "direct" instead of networked, resulting in 2nd level APIs that repeatedly send 10mb of unintialised _crap_ over-the-wire.
then, later on, once the proprietary push of DCOM onto the world failed, microsoft tried again with CLR. CLR has been slightly more successful, as it is not tied historically to the operating system.
the bottom line is that there is plenty of technology out there for cross-application communication that makes it perfectly possible to have really quite sophisticated applications written in different languages.
DCOM. DCE/RPC. JSONrpc. Objective-C. CLR/.NET. even CORBA, god help us.
all of these have varying degrees of sophistication _well_ beyond "pipes and text file formats" that have developers throwing up their arms either in horror or to scratch their heads.
and it's exactly the ignorance and the lack of appreciation for these powerful technologies that leaves you, cthonicdaemon, in the situation that you are presently in.
Do you see the Web-Browser-As-OS implemented as a virtual machine capable of running inside another operating system?
hopefully not - or if it is, i'd hope that it would be more along the lines of an "assisted" VM - you know, making use of those vmx or svm flags on modern processors. so - more like XEN and KVM than an "abstract" virtual machine.
what would be really out-of-order would be to use a java or a CLR (.net) virtual machine architecture. an actual operating system running on top of those would be a complete disaster.
you'd think, wouldn't you, though, that it would be possible to do a decently-designed browser, with pages running as separate applications, that all properly coordinated and ran as part of an existing OS, though? :)
Stick a full VM into the browser. Problem solved. Except of course for the huge resources needed to view even the simplest of pages.
The entire push over the last few years to transferring processing load back onto the client is the wrong direction in my opinion, and the browser should remain a THIN client like the original intent. Keeping it a thin client by nature would be secure.
noooo, nonono can do - yes it would be secure, but times have changed _drastically_. what's happened is that as the desktop wars got ridiculous (and i don't just mean between different OSes, i also mean between win95, xp and up), people simply moved to the browser itself to provide access to applications. all the talk of "ubiquitous computing" has actually _happened_.
and, as the expectations of web infrastructure got ever greater, that origial "thin client" architecture began to look... well... thin! so along came flash, and javascript, and god help us java, and then AJAX, and then GWT and Pyjamas which _really_ make it clear that the browser really _is_ just another "widget set" like Python-QT4, Python-GTK2 or Java Swing, and somewhere rather unfortunately along the line silverlight got added to the mix.
and once you're down this road, there really is no turning back. you're now running complex comprehensive applications such as gmail.com, google apps and WebOS and i do _mean_ applications side-by-side in the same "space" and it's just getting too much for the poor little browsers, which were never designed to act as "operating systems".
so i think what we're seeing here is the recognition of the fact that browsers have to become what OSes were designed to do, because browsers are now taking over from what OSes were _supposed_ to be doing, because everyone's moving inexorably to online interaction, now, instead of "isolated desktop".
so is anyone _really_ surprised that the solutions proposed are to use tried-and-tested proven technology, just moving it to where the focus has gone? current browser technology can be compared to OS technology of the Windows 1.0, GEM/DOS and early Mac era!
i always wanted to write my own desktop, like webos or the example/demo that comes with extjs, using browser-based technology. then i can throw away all the silly desktops i never liked anyway, and run all my applications from inside the web browser. and, because i know that the browser technology is actually an OS, i know it's secure and also will have process-separation so that one app crashing won't take out my entire quotes browser quotes. hooray!
no see my earlier posting on this subject: the use of Security Descriptors and potential checking against the PDC is what makes process creation expensive, which then makes _thread_ creation so cheap in NT, by comparison. ... you can't really secure threads from each other, so why bother, basically, was the general attitude that can clearly be seen to have been taken.
short answer: the ACL-based security model, which is transparently networked onto "NT Domain Security".
the design comprises:
* the evaluation of the security descriptor, which is a binary blob that needs to be decoded
* the creation of a process, where the parent has a security descriptor "inheritance" chain to its parent, to its parent etc. etc.
* the possibility for evaluating an individual ACE that could be on a remote machine (a PDC)
* just the _possibility_ of having to contact the remote machine (the PDC) leaves a design where the creation even of a local process requires the use of MSRPC (on "local rpc" pipes - ncalrpc) in order to not drastically overcomplicate the code any more than it already is.
goodness knows what else is going on, but it's very very powerful but unfortunately with that power and flexibility of design comes a whopping great overhead.
and no you can't cache the results very much because someone might revoke a user's right to CREATE_PROCESS and they'd get a bit unhappy about that not being obeyed.
why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop
I could see a case for it. I could also see a case for doing it WITHOUT modifying the full range of OS technology. Why is it so hard to see that a secure browser could be done using existing operating systems?
sorry, i assumed it would be clear. applications running within the browser are becoming more like _real_ applications - _real_ "desktop" applications, especially with downloadable-executable-code ( "plugins" such as as adobe ) having been thrown into the mix.
and you have multiple of "applications" running simultaneously.
therefore, you have security implications, application stability implications, and much more [i recently had firefox crash out-of-memory on linux, and i have 2gb of ram and 3gb of swap space].
therefore, you need to start looking at isolating the applications from each other, whilst also allowing them access across a common API to a central set of protected resources (screen, keyboard, mouse, other devices, memory, networking), to be able to communicate across that boundary without impacting any other applications or the central resource management layer itself.
and i think you'll find that if you look closely, that's pretty much the definition of an OS.
so, working from the requirements - the expectation that good, hostile, rogue or simply badly designed applications all need to be given a chance to run, you arrive naturally at the rather unfortunately-logical conclusion that the only decent way to fulfil the requirements is with an actual full-blown operating system.
to believe that anything else can fulfil the requirements, to provide multi-tasked application stability and security, really is sheer delusion, or is... like... expecting a 1980s apple mac OS with a 68000 CPU and no Virtual Memory support, to be "secure". ... actually, there _is_ one other possibility: Security-Enhanced Linux (specifically, the FLASK security model behind SE/Linux). and we know what people think of _that_, despite SE/Linux being incredibly good at its job.
i've done event-driven vehicle simulators; i've clean-room network-reverse-engineered MSRPC and NT domains protocols; i've ported freedce to win32; i've added glib bindings to webkit and on top of that, ported a port of GWT to python even _more_ into python by adding DOM manipulation to pywebkitgtk.
in amongst all that mindless drivel of alphabet soup you should be getting a pretty clear picture that i'm not a stranger to complexity.
i've learned that if someone says "surely it doesn't have to be as complicated as all that", it's time to run like stink as fast as possible, out of the conversation and the room, and never look back.
browsers are effectively desktop technology within a desktop (and damn good at displaying widgets), except you're letting the web site dictate what "programs" are allowed to be "run" on your desktop^H^H^H^H^H^H^Hbrowser.
browsers are no longer "just HTML displayers", they are actually executing applications - _real_ applications - that in many instances happen to be written in javascript. GWT, Pyjamas and RubyJS should all hammer that point home.
with that in mind, why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop^H^H^H^H^H^H^H^Hbrowser technology?
ahh, but not by me :)
X... V... oh _god_!!! ha ha :)
am i missing something, here? if it's the "final" fantasy, how come there's eight of them?
Does it really matter if the algorithm is found to be flawed later on, if most of these packages support algorithms known to be flawed today?
does it matter? does it matter?? fuck me it fucking matters.
example 1
there's a type of encryption algorithm principle - the feistel cipher - see http://en.wikipedia.org/wiki/Feistel_cipher - where you perform one simple transform function as "round 1", then for rounds 2 and 3 you do a one-way hash function, and then for round 4 you do a simple transform function.
if the one-way has is ever broken, your encryption cipher is also broken.
game over: any traffic that's ever been using that cipher can be decrypted.
example 2
your credit cards you carry around? the PIN number isn't stored on the card - but an MD5 hash of the PIN number *is* stored on the card (making replay attacks possible, believe it or not).
if MD5 is ever cracked...
game over: anyone can get your PIN number.
example 3
your peer-to-peer filesystem, your git source control system, they use one-way hashes to store an index of the data blocks. let's say that someone deliberately wants to break deployed systems, they work out what file chunks could end up being mapped to the same one-way hash...
game over: anyone can corrupt the database or the peer-to-peer filesystem by _deliberately_ making file or file chunks write to the same block.
i could go on with the list of examples - authentication systems that would fall over; internet bank systems that could be broken in to - we _totally_ rely on one-way hashes working correctly.
it's important beyond _belief_ that these one-way hash functions work, so much so that i was staggered that the question even had to be asked as part of the article-announcement.
"She's just a low-level drone who is only source of information..."
now, children: please, allow me to correct you in case some grammar nazi (other than myself) comes along and rebukes everything you say, on the basis that poor spelling must indicate poor attention to detail and poor ability to reason. like.
the word you are looking for is "whose". "who's" is, as you know, a contraction of "who is".
as an anal attentative grammar nazi and long-time linux supporter and free software advocate, it would be much better that i get to you first before that teacher, or any of her "slazhdot-readin suhporturs" do.
fricking fricking anonymous posting! :)
clicked the wrong damn button ha ha
the best way to think of all these smartphones is as a combined phone + laptop on one circuit board, where they're even connected together using USB.
so what these embedded OSes do is quite literally nothing other than send "AT" modem commands (and sometimes a bit more, using escape sequencing) to the on-board modem chipset.
so, unless you start hacking the firmware of the on-board modem, you will still remain within the FCC regulations.
however, some of the cheaper smartphones - in particular the ones based on the TI OMAP series - run a dual-core processor - a TI ARM core plus a TI DSP core - typically a 200mhz one (because lower than 200mhz is utterly useless for smartphone features. but hey, it's cheap).
these phones _are_ a serious risk, because the two CPUs share memory (!) and you can reprogram the registers etc. etc. you can look up exactly how to do it.
anyway, the point is: the radio modem firmware is downloaded _directly_ to the processor, where all of the signal baseband processing is done. things like the GSM signal-strength of the radio can be manipulated DIRECTLY by changing a memory location, using the ARM cpu.
or worse.
clearly, this is bad.
however, the design of the more expensive HTC-designed phones - typically involves a _much_ better setup - with "standard" 400 to 600mhz ARM cpus and a completely isolated "standard" chipset.
the price of the G1 is indicative that it is one of these better setups.
if you want more info, here's where you're going to get it - from the xda-developers and the #htc-linux irc channel on freenode.net. DO NOT waste the developers time on #htc-linux - they are NOT paid to work on the reverse-engineering of HTC phones, but have stuck diligently to the task for over four years, nearly five now, to bring _proper_ community-driven support for linux to these hand-held smartphones.
forum on G1 dev:
http://forum.xda-developers.com/forumdisplay.php?f=448
page listing android devices:
http://wiki.xda-developers.com/index.php?pagename=Android_devices
as people do reverse-engineering and/or find out other information (such as take the backs off and photograph the chipsets) you'll find the info listed, there.
http://git.koolu.org/
i've just heard back from the developers - it's not in the slightest bit a dead or dormant project. the developers are university students. busy and unpaid ones.
But hey, gotta go for every low blow you can get while the news is still fresh, right?
you gotta press those slashdothers' buttons in juuust the right way...
Git is basically just a generic distributed versioning-filesystem layer, right?
yep.
Source control is its current killer app, but it's got no particular hooks to make it dependent on that domain.
nope.
So if we combined Git + Bittorrent... does that give us a generalised peer-to-peer distributed filesystem?
yep!
If so, that's a whole lot more interesting than just a way to share source code fast.
oh yeahhhh :) e.g. GitFS - http://www.sfgoth.com/~mitch/linux/gitfs/
Imagine a true peer-to-peer Web built on something like this.
Imagine, for instance, posting blog or wiki posts as little paragraphs of text, each as a separate file, not uploaded to a 'server' but just put out onto the grid. Cache every chunk of data as it moves through servers, maybe have a name-resolution layer like DNS over the top so that one server is 'authoritative' for your blog posts, but that server doesn't need to be online all the time as long as another one has replicated the data. Add a language which allows transclusion of chunks and/or functional manipulation of them, so you don't have to use messy AJAX tricks which bust the caches.
We could get a few steps closer toward Xanadu.
hey, can you ghost-write my next article on this subject, for me? :)