Slashdot Mirror


The Next Browser Scripting Language Is — C?

mad.frog writes to tell us that in a recent talk by Adobe's Scott Petersen he demonstrated a new toolchain that he has been working on (and soon to be open-sourced) that allows C code to be run by the Tamarin virtual machine. "The toolchain includes lots of other details, such as a custom POSIX system call API and a C multimedia library that provides access to Flash. And there's some things that Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM, thereby allowing the VM's "emulation" of memory to have only a minor overhead over the real thing. The end result is the ability to run a wide variety of existing C code in Flash at acceptable speeds. Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music."

375 comments

  1. Browser-based OS by rustalot42684 · · Score: 4, Funny

    Now we can finally get this "web operating system" thing I've heard so much about...

    1. Re:Browser-based OS by Darkness404 · · Score: 1

      And perhaps this will make open-source web apps possible and needed.

      --
      Taxation is legalized theft, no more, no less.
    2. Re:Browser-based OS by rustalot42684 · · Score: 0

      well, it says it's going to be "open-sourced" but it's not clear that that even means anything because afaik it's based on flash.

    3. Re:Browser-based OS by rustalot42684 · · Score: 2, Informative

      Er, disregard that, I was wrong

    4. Re:Browser-based OS by Hatta · · Score: 5, Insightful

      Well this just underscores how silly the whole web-application thing is. An application running on a browser is a silly idea for the same reason an OS running on a browser is. We already have operating systems to run programs on. Give us native programs, not some horrid mishmash of technologies.

      --
      Give me Classic Slashdot or give me death!
    5. Re:Browser-based OS by Darkness404 · · Score: 1

      Well, I was talking about the C applications not the framework they are based on.

      --
      Taxation is legalized theft, no more, no less.
    6. Re:Browser-based OS by Yold · · Score: 4, Insightful

      What the hell are you talking about? Web applications have some really good uses in the real-world (read business world). Instead of updating every computer in the office with a new version of some data management app, it is deployed once.

      Native programs are optimized for speed, Web Applications are optimized for Rapid Application Development. Remember visual basic? Thats what web apps do nowadays, and trust me, its better.

      As for "your horrid mishmash of technologies" statement, I agree that AJAX is overused, but believe me it is very nice to be able to do stuff on the server side (think form validation), and then not have to redo on the client-side in javascript.

    7. Re:Browser-based OS by rustalot42684 · · Score: 2, Insightful

      Right, I got that. My point was that it's not really a very good idea to build open-source programs which are dependent on some proprietary library/toolkit/framework/etc, especially when the proprietary part is very large and complex (eg Java), or when a free alternative exists but the original remains patent-encumbered (Mono). If the underlying framework is proprietary, the freedom of the other software is made irrelevant by the fact that the owners of the framework have total control over it. Things can resolve themselves, however; see the KDE free Qt foundation as an example.

    8. Re:Browser-based OS by Anonymous Coward · · Score: 4, Funny

      You need an operating system to run programs? Bah! Real programmers aren't afraid of programming directly to the hardware.

      This whole operating system fad won't last. Who wants to waste so many resources just to simplify development and portability? If we don't stop this operating system fad quickly, the next thing you'll see is people developing virtual machines so that girly programmers won't have to have to test their applications across various platforms. And then they'll start integrating these virtual machines into normal applications! What are they thinking? That memory and processor speeds are growing exponentially?

    9. Re:Browser-based OS by Whatanut · · Score: 5, Funny

      If you run a browser based OS... and install a browser in it. And then use that to run a browser based OS, why... we could have infinite amounts of computing power! Or space time will tear itself apart. Either way, I'm making popcorn.

      --

      yvan eht nioj
    10. Re:Browser-based OS by peragrin · · Score: 1

      Oh come on now can't you see the money flow.

      MSFT can charge for Vista and Internet Explorer separately.

      Of course the question one has to ask if a browser that is free can run applications as well as the underlining OS can what purpose does the OS serve?

      The secret to network aware applications is to move them to the browser? guess that is one way to push standards.

      --
      i thought once I was found, but it was only a dream.
    11. Re:Browser-based OS by bestinshow · · Score: 5, Insightful

      Not really. I do agree that native applications are nicer than web applications, especially if you compare, e.g., Google Docs to Office, or even WordPad.

      However what we have discovered is that (1) web applications are easier to write, and (2) it's nice having a consistent platform to develop to, even if that platform is mildly ridiculous (HTML + CSS + JavaScript + Browser-Workarounds + JavaScript canvas thing). Getting stuff to display and layout on this platform is easy, and simple to prettify, far easier than most native platforms have been in the past. There are also a dozen different ways to write the server side of things, and I think for many developers it is nice to be forced to split up the client interface from the meat of the system.

      Of course, things are going too far. What should be happening is the simplification of native application programming, with a common platform, etc, without the overhead of having to run a Javascript or HTML rendering engine, and native full-speed canvases. I think that Apple is getting there, QT and KDE4 may be getting there but I haven't really looked into that platform. Java should have gotten there but early design mistakes (AWT, Swing) have killed that off, and SWT is a last-generation UI library. Maybe something like Fenggui on Java might help this platform, but I think Java's dead on the home desktop (and extremely alive and profitable on the server).

    12. Re:Browser-based OS by rustalot42684 · · Score: 4, Insightful

      Instead of updating every computer in the office with a new version of some data management app, it is deployed once.

      Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved.

      A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers. What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time. You get the speed and the portability and the UI consistency and the tech support only needs to support one program.

      I agree with you, however, that web apps are the new Visual Basic. They're slow, crappy, and often insecure.

    13. Re:Browser-based OS by Hatta · · Score: 3, Insightful

      Web applications have some really good uses in the real-world (read business world). Instead of updating every computer in the office with a new version of some data management app, it is deployed once.

      Oh come on, it's not that hard to push an application onto every computer in the office. This is a cop out.

      Native programs are optimized for speed, Web Applications are optimized for Rapid Application Development. Remember visual basic? Thats what web apps do nowadays, and trust me, its better.

      Then use python with wxwidgets or something. Every bit as easy and portable, a lot faster and safer.

      As for "your horrid mishmash of technologies" statement, I agree that AJAX is overused, but believe me it is very nice to be able to do stuff on the server side (think form validation), and then not have to redo on the client-side in javascript.

      Frankly, you should be doing everything on the server side.

      --
      Give me Classic Slashdot or give me death!
    14. Re:Browser-based OS by ultranova · · Score: 1

      Now we can finally get this "web operating system" thing I've heard so much about...

      Well, Linux is written in C, so...

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    15. Re:Browser-based OS by Yold · · Score: 5, Insightful

      #1, Yes, it is hard to push out an application to every University computer when you are at one w/ 50,000 students.

      #2, see #1

      #3, everything is done on the server-side, and prior to AJAX, it was redone in Javascript on the clientside for a more responsive user interface. Now, both the client and server use the server-side procedure.

    16. Re:Browser-based OS by trolltalk.com · · Score: 1, Informative

      It's not a browser-based OS - it's just a mapping of c source code to an interpreter running in flash.

      So it will be slowwww. In other words, it will turn your dual-core into a 386.

      Also, who the f*ck puts black text on a dark-brown background? If you don't want us to read the article, just say so ...

    17. Re:Browser-based OS by LilGuy · · Score: 1

      But will it allow you to divide by zero?

      --

      You're nothing; like me.
    18. Re:Browser-based OS by sjames · · Score: 4, Funny

      Sonny, back in the day we didn't need a machine to test our code. We ran it in our heads as we punched it into the cards. Sure, there were a few new guys who used pencil and paper to help them, but if they didn't shape up in a month or so, we ran them out of the industry.

      Now get off my lawn!

    19. Re:Browser-based OS by Yold · · Score: 0, Redundant

      There are some very talented web-developers, and there are some very intuitive web applications. But yes, there are many slow, crappy, and insecure ones out there too.

      Linux doesn't work well in the business world for ordinary users. Trust me. It doesn't. They need stuff that is windows only.

      Prototype solves a lot of the DOM incompatibilities between IE/Firefox.

      My point is, web apps do RAD very well. Native apps give you flexibility. But such flexibility is not required for run-of-the-mill data management apps. I don't want to write something to manage updates, the very nature of a web app eliminates the need to do that. If I am going to write something at home, I'll do it in C. But I'd rather do a project as quickly as possible, it gives me more time to post on Slashdot ;)

    20. Re:Browser-based OS by Hairy+Heron · · Score: 5, Informative

      especially when the proprietary part is very large and complex (eg Java)

      You're about 3 years out of date on calling Java proprietary, kiddo. In case you forgot, it's been GPLed for over a year now.

    21. Re:Browser-based OS by hitmark · · Score: 1

      or one could go back to big irons, and issue the work force wifi/3G equiped "terminals"...

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    22. Re:Browser-based OS by mweather · · Score: 0, Troll

      If your sysadmins were worth a damn it wouldn't matter if you needed to push updates to 5 computers or 50,000.

    23. Re:Browser-based OS by sconeu · · Score: 5, Funny

      So it's browsers all the way down?

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    24. Re:Browser-based OS by AllIGotWasThisNick · · Score: 0, Redundant

      we could have infinite amounts of computing power!

      So, you're saying it's browsers all the way down?

    25. Re:Browser-based OS by bheer · · Score: 1

      Browser-based OS? How about Inferno, open source since 2005, from the guys who brought you Unix. They even had an ActiveX plugin available back in the day.

    26. Re:Browser-based OS by Surt · · Score: 1

      You can't do everything on the server side and be scalable. There's a lot more cpu/memory on 100,000 clients than there is on any server.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    27. Re:Browser-based OS by avk77 · · Score: 1

      Oh you mean like java web start?

    28. Re:Browser-based OS by _anomaly_ · · Score: 1

      Of course the question one has to ask if a browser that is free can run applications as well as the underlining OS can what purpose does the OS serve?

      ...to run the browser in the first place?
      Chicken and the egg...

      --
      "I have no special gift, I am only passionately curious." - Albert Einstein
    29. Re:Browser-based OS by gladish · · Score: 2, Funny

      FYI: RAD is short for radabonzical and not rapid application development, and guess what? PyPy is gonna beat out flash simply for namesake. Just think of all the new wrappers we can write. PyPyTk, PyPyGL, PyPyMySqlAdapter, PyPyList, Vector, etc. I'm totally psyched for PyPy. Or maybe we should write Gnome bindings... GnomePyPyHashSet. You can dance to that one.

    30. Re:Browser-based OS by Eli+Gottlieb · · Score: 1

      What the hell are you talking about? Web applications have some really good uses in the real-world (read business world). Instead of updating every computer in the office with a new version of some data management app, it is deployed once.

      Why has nobody ever heard of remote X forwarding?

    31. Re:Browser-based OS by Anonymous Coward · · Score: 0

      Floating point already allows you to divide by zero. You get infinity.

    32. Re:Browser-based OS by JebusIsLord · · Score: 2, Interesting

      Using a package management system does not make for "poof! problem solved." At work we have an entire team of packagers, plus ~1500 applications to maintain. Library conflicts and such are a nightmare, as are bad vendor packages.

      Web apps honestly aren't much better... they usually tie you to a specific version of IE (activex) or Java (even worse in my opinion... i think we have 5 or 6 different slightly incompatible runtime packages out there now).

      --
      Jeremy
    33. Re:Browser-based OS by bugeaterr · · Score: 1

      Now we can finally get this "web operating system" thing I've heard so much about...

      Can your browser OS run Vista on a VM?
      If so, would it boot up before Windows 7 is released?

    34. Re:Browser-based OS by Nar+Matteru · · Score: 1

      Also, who the f*ck puts black text on a dark-brown background? If you don't want us to read the article, just say so ...

      The area where the actual text is has a white background....

    35. Re:Browser-based OS by LarsG · · Score: 1

      c|n>k

      I was drinking coffee when I read that, you insensitive clod!

      --
      If J.K.R wrote Windows: Puteulanus fenestra mortalis!
    36. Re:Browser-based OS by Anonymous Coward · · Score: 3, Insightful

      "Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved."

      What if your office runs Windows, Mac OS X, Symbian OS, Debian, Plan 9, Red Hat, MS-DOS and OpenBSD?

      I don't know about you, but I'd still rather just update a web application. There are many ways to solve the cross-platform issue, but the web's a particularly zippy one that's very easy to develop for, so why not?

    37. Re:Browser-based OS by grasshoppa · · Score: 4, Insightful

      Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved.

      That certainly is a simplistic concept. Now, let's talk about largish environments. You know, where the user is running as a limited user, therefore the app can't update itself. Or where windows is required, so we can't use linux's update mechanisms.

      Or how about the simple logic that updating one app once is more likely to go smoothly than updating one application 100 times. Or a thousand. No matter how automated, problems crop up.

      Honestly, if you are going to argue the point, at least think about your arguments first.

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    38. Re:Browser-based OS by afabbro · · Score: 1

      CARDS!?!? You needed cards? Back in my day we were just figments of a possible future reality and our programs ran just fine without all these fancy technological crutches like "the universe" and "reality" and such.

      --
      Advice: on VPS providers
    39. Re:Browser-based OS by pintpusher · · Score: 1

      What if you write the browser to run on bare metal? What then? The browser could provide all these interfaces for accessing the hardware (could probably even get hardware manufacturers to write the code to glue their hardware to the browser). For example, the browser could provide methods for storing and retrieving data from persistent data stores like hard drives. Then the browser could pull applications from the net to allow the user to do things like write documents or draw graphics, etc. Finally because sometimes the network goes down, and to save on bandwidth costs, the browser could actually save this downloaded code to the persistent storage. Then the user could access their documents and programs directly from that storage and do their work anywhere they happen to have their computer -- even without a network connection!

      --
      man, I feel like mold.
    40. Re:Browser-based OS by trolltalk.com · · Score: 1

      Not on opera/linux. I had to highlight the text to read it.

    41. Re:Browser-based OS by Anonymous Coward · · Score: 0

      Ah yes. Nothing worse than a development team hit by a waveform decollapser.

    42. Re:Browser-based OS by Colin+Smith · · Score: 1

      Why has nobody ever heard of remote X forwarding?

      The I.Q. of any group tends towards the mean.

       

      --
      Deleted
    43. Re:Browser-based OS by euice · · Score: 1

      I guess it's a troll, otherwise he wouldn't have implied that the "kde free qt organization" is something about freeing kde from qt, where it is a nice agreement to secure kde even more rights on QT in case of Trolltech stopping developement, besides you can use all important (and almost all unimportand) QT libs under the terms of the GPL.

    44. Re:Browser-based OS by jsebrech · · Score: 4, Insightful

      A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers. What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time.

      That still doesn't solve the deployment problem. You need rights on the local system to install that software. Why do you need those rights? Because native apps can interact in too many ways, and they can't be trusted, so rights are not automatically granted.

      The clever thing about the web platform, and what sets it apart from other platforms, is that the security model by default lets you run any app, even one you don't trust, on any system, without it causing major catastrophes.

      The web platform is building on a new concept: ubiquitous internet. The idea is that your applications and data live in the cloud, and are available to you on any device, anywhere, any time. Off-line support is only necessary as a short-term stopgap until the cloud is visible again (like the offline support of google docs).

      This is why the web makes sense: it just works. No installs, no administration, no lost data when your local machine fails, no shuttling different versions around on usb sticks. It's true that it's less powerful, but it doesn't matter because the ease of use gained from having the apps and the data "out there" will vastly outweigh the lack of capability for the majority of users.

    45. Re:Browser-based OS by Anonymous Coward · · Score: 0

      Your retarded

    46. Re:Browser-based OS by Ant+P. · · Score: 2, Insightful

      What if your office runs Windows, Mac OS X, Symbian OS, Debian, Plan 9, Red Hat, MS-DOS and OpenBSD?

      You're fucked either way. Ever tried developing a complex web app that runs on even 7 out of the 8 of the above?

    47. Re:Browser-based OS by Anonymous Coward · · Score: 0

      Java is not proprietary anymore...

    48. Re:Browser-based OS by Haeleth · · Score: 1

      Hell, even the Microsoft-loving fanatics who think X11 is the Mark of the Beast should at least have heard of Citrix.

    49. Re:Browser-based OS by Tablizer · · Score: 3, Insightful

      Well this just underscores how silly the whole web-application thing is. An application running on a browser is a silly idea for the same reason an OS running on a browser is. We already have operating systems to run programs on. Give us native programs, not some horrid mishmash of technologies.

      Ideally, web apps should have 3 main advantages over native apps:

      1. Easy deploy-ability - No "install" step

      2. Vendor-neutral user-interface conventions - Developer only writes to "web standard" and not to Windows nor KDE nor Mac, etc. (X-windows tried to be this, but it is not HTTP-friendly.)

      3. Sandbox Security - The web app would not be able to touch local resources, such as user's file system, without explicit permission.

      In practice, it has not been quite that simple. For one, standard web interfaces have lack-luster and incomplete widget choices. And, different browsers support JS/DOM differently.
                 

    50. Re:Browser-based OS by Anonymous Coward · · Score: 0

      #1. No, it's not. Read: Boot from LAN.

      #2. The number of students is irrelevant, as they are not computers, and this discussion is about number of applications/computers and has nothing to do with students, or their personal machines.

      #3. Everything you did, maybe. The people wanting to run reliable web services put server stuff on the server and client stuff on the client, we don't "redo" server code on the client or vice versa. Try it, it works.

    51. Re:Browser-based OS by DarkOx · · Score: 1

      A terminal server serving up rich applications, is a much much better user experience then anything being done in current web applications. It addresses all the problems you mention. Infact it addresses some of them better, as you can give your destop users little wise terms at some point then you no longer have to worry about upgrading destops nearly as often. Sure once in a great while maybe 6 or 8 years you are going to want to replace those terminals, but I doubt more often certain not the 18 months to three years desktops usually are being cycled. Oh and your out of data center maintenace goes to zero. Generally its not much harder to maintain your terminal server farm them the application servers you would have on the back end anyway running either your web applicaion or supporting your fat client.

      The web app is good for simple things, IT IS NOT A GOOD SOLUTION FOR HALF OF THE STUFF PEOPLE ARE TRYING TO DO. I don't know many organizations that ask uses to use OWA at their desks, OWA is at least with exchange 2007 about a nice as web apps can get at least when used on IE. Still most people run the Outlook client at least when they have their own PC and are in the office. There is a reason for doing that, the fat client is a better experience.

      This is interesting though if you can just turn around and rebuild your C/C++ fat app whith this tool chain and launch it from a browser this might be really good. Somehow you have to get outa the sandbox in a safe way though. If you can't hock into the native libraries and do IPC with other apps then its just going to be another JAVA it won't look nice, it won't integrate well with whats already running and won't be used.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    52. Re:Browser-based OS by Anonymous Coward · · Score: 0

      I think this is really cool, as long they open source it and make an open standard.

      I really think its stupid that they come up with a new language for every damn thing. C (well, C++ really since it has OO part and templates) does everything that language should do.
      For example, you can write very fast low level stuff (think embedded 8-bit PIC micros) in C, or you can write high level GUI stuff (think Qt or GTKmm).

      C/C++ really can do everything and they can do it in a really good and efficient way.

      What kills me is that most people that complain about C/C++ and write another language come up with the same old thing, except they have a more complete standard library. What I mean is this: standard C does not have sockets in standard library, but all new languages do (think Java, C#). Really though, basic Java or C# do not really do much more than standard C or C++ for example. The main difference is the standard library.

      What one should really do is come up with a really good standard library type of deal that extends the basic C or C++ language with functionality like threading, XML, GUI, web applets or sockets.

      Once you program in a library such is Qt, you realize how powerful C/C++ really are if you have really good library to work with. You get all the nice and easy features such is .NET for example, yet you do not suffer the performance hit.

      I think Boost is a step in right direction, except they need to standardize function naming and namespaces better. I think Qt is a very good example of a very well written C++ library that is easy to use. Even GTKmm is very well written, except in my opinion I think that the whole GUI generation is kind of crappy (I'm talking about the XML files that you have to load in your code - why not just generate a set of include/.h files that have the window layout in it?).

      Another thing that would be really nifty is implementing a library that mimics the layout of the .NET library for example. I think out of all libraries, .NET has a very well done layout (ok, maybe its not perfect, but its much better than a lot of other ones available).

      So for example, instead of having xml functions from xmllib under like
      namespace xmllib
      {
        xml_load();
      }
      and having thread stuff in std namespace pthread_create()

      why not put together a nice standard library that has outline like this:

      namespace System
      {
      namespace XML
      {
      xml_load();
      }
      namespace Threading
      {
      thread_create();
      }
      }

      or something similar to that so its all in a nice and logical arrangement.
      That way when I want to create a thread, I don't have to go dig through tons of documentation to find wtf is the name of the thread functions.

      I can just use System::Threading:: and the code completion will do the rest.

      C/C++ could easily blow away all the other languages if they had a good standard library. If you think that this is crazy talk because C/C++ is too old or too hard, then getOfMyLawn(), otherwise if you think that this is crazy talk because (namespaces are evil, code completion is evil, it will just make it bloated, e.g. pick one), then go back to using magnets/vim/punch cards/dials/cobol or whatever the hell it is that old people use :)

      Seriously though, it is not impossible to implement a nice library like that. Again, Qt is a good example.
      I'm not saying to make this part of a standard language. I'm saying to make this an addon, an open standard. Something like Boost or Poco library, except make it more complete and more organized. Include basic stuff like GUI, sockets and threading first and then worry about adding crazy ass algorithms. The Poco (portable components) library is a good start, but they have a lot of ways to go yet.

      Making a C web library is a good addition to all the other platforms that C runs on. Example being FPGA (http://en.wikipedia.org/wiki/Systemc, or http://en.wikipedia.org/wiki/Handel-C), GPUs (CUDA) etc.

    53. Re:Browser-based OS by kundziad · · Score: 3, Insightful

      Or where windows is required, so we can't use linux's update mechanisms.

      The truth is that Windows is a corporate OS too (or... in the first place), so it has perfectly working corporate software management mechanism. You just have to be maintain it well and have support from the application developers (who need to stick to good practice while coding their applications - that's usually the most difficult part).

    54. Re:Browser-based OS by bill_kress · · Score: 2, Insightful

      >Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved.

      There are a couple apps that I will never run outside a browser again.

      Mostly Gmail and Google docs.

      You literally cannot offer any significant improvement by running it native, and you remove their primary abilities when you do so.

      I can access my gmail on virtually every platform, from a PC in my local coffee shop to almost any phone to any "non-mine" computer in the world.

      Google apps gets to be the same way--I keep notes on their word-processor (like snippets of code I might need elsewhere), share documents/spreadshets for collaboration, and keep important documents with information that I may need to refer to from elsewhere.

      Finally google maps.

      All these apps have native alternatives--and I have used them. I never will again.

      Although there are issues with the way they are usually implemented--a toolkit like GWT reduces quite a few of the variables since something like a browser incompatibility or security issue can be addressed in one place (within the toolkit) and not in 30 places within your app.

      I'm not saying that browser apps are the only way to go--there are obviously issues--but you certainly would block yourself off from a lot of extremely appropriate usage scenarios if you took an absolute stance against them.

    55. Re:Browser-based OS by CastrTroy · · Score: 1

      From what I read, it seemed more like you had a VM running inside your browser window. So you'd get something more like VMWare or Parallels but only in the browser window. You can get pretty good speed running a VM outside the browser. As long as you aren't running on a different architecture, I don't see why this couldn't very responsive.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    56. Re:Browser-based OS by benhattman · · Score: 1

      I don't quite get the joke, but shouldn't this be modded funny and not insightful?

    57. Re:Browser-based OS by jellomizer · · Score: 1

      Because remote X forwarding is dependent on a continuous connection to the server, with all the processing being done on the server and X Windows compared to web design is a pain to program.

      Using Web for applications other then X you can download the layout and some of the interface instruction then it can disconnect from the server allowing the application to scale, as you can have 100 people using the app with only 25 active connections at once, with the bulk of the UI interface and checking running on the users CPU not the server.

      HTML format is much easier to code for then X11. For most server language you can get by by using Post Forms and post Ajax methods. Taking the Query String via stdin or for Get methods getting the environmental variable (heck you can make some complex web apps with just shell scripts) and print the HTML vis. StdOut... With the Content-type: text/html\n\n as the first output. You are not fussing trying to get the window to draw etc.....

      X forwarding is a dead technology it was never completely utilized as it was designed. The clients now run close to the same speed as the server, so using Remote X is just putting load on the server that you can be putting on the client. X windows is basically used as a frame buffer for OS's sure you can remote X some apps. But even over a good speed Broadband line, It runs sluggish, as it sends a lot of data just for display use only and it sends back a lot of information too.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    58. Re:Browser-based OS by grasshoppa · · Score: 2, Insightful

      I'm not so sure I'd be willing to call it a "perfectly working corporate software management mechanism".

      MSI is a decent format...sorta. However, the format itself allows for all sorts of abuse ( binary executable wrapped up in a MSI? Sure, been there done that ). Further, configuration is often dependent on the developers writing the tools for custom configuration transforms( as apposed to a simple text ini file ).

      While MSIs are useful when employed correctly, I'd hardly call it perfectly working. Hell, it'd be a stretch to call it corporate since it doesn't have any built in reporting features.

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    59. Re:Browser-based OS by Phantom+of+the+Opera · · Score: 1

      Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved.

      Its solved if you have a homogeneous environment. Where I work, people use Mac, Windows and Linux as desktop systems.

      A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers. What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time. You get the speed and the portability and the UI consistency and the tech support only needs to support one program.

      Many web apps are merely data reports with minor munging. The performance differences in execution speed are made moot by network latency and thruput.

      Yes there are different browsers out there, but you can be mean and put your foot down and say. "Use Firefox".

    60. Re:Browser-based OS by Eli+Gottlieb · · Score: 1

      AHHhh, you can talk technical. OK, well I'm actually engaged in a minor effort to create a client application that will connect to another machine and somehow "import" a native application from that machine for local use. Currently I'm using X forwarding over SSH to do that, but only because I ran into a problem with my initial design.

      My initial thoughts ran exactly along the lines you detailed when I went through them: X forwarding uses too much bandwidth and server processing time. So I thought, rather than use X forwarding, I could take advantage of Linux now incorporating 9P2000 drivers in the mainstream kernel. The server of this little application service would provide a filesystem containing the native applications it can serve over 9P. The client program, to run an application, would fork a new process to do the following:

      1) If the appropriate server's file-system has not been imported, mount it over 9P to a temporary directory used as a mount-point.
      2) chroot into the mount-point of the appropriate server's file-system, both protecting the client system from malicious server code and providing the server's code with a layout it recognizes.
      3) Exec the desired application.

      While this would result in a permanent connection, data would only be transferred over the network when the client needed a part of a file that it didn't have cached. Both processing and drawing would take place on the client machine.

      Of course, the problem I ran into is that without root privileges no process can change its own view of the file hierarchy (a la Plan 9) nor chroot. I understand that this prevents obvious security attacks based on malicious programs run with setuid privileges, but is there any way to simply disable setuid, run everything as user, and perform the chroot any-damn-way?

    61. Re:Browser-based OS by Zero__Kelvin · · Score: 1

      "Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music.""

      "So it will be slowwww. In other words, it will turn your dual-core into a 386.

      Also, who the f*ck puts black text on a dark-brown background? If you don't want us to read the article, just say so ..."

      I see your excuse for not RTFA, but what is your excuse for not reading the summary. Even on Slashdot, one is expected to at least read that much before posting! ;-)

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    62. Re:Browser-based OS by rustalot42684 · · Score: 1

      I guess it's a troll, otherwise he wouldn't have implied that the "kde free qt organization" is something about freeing kde from qt

      Actually, I wasn't making that point at all. I was using Qt as an example of a situation where things started in a non-ideal situation, with a non-free license, but over time, TT first licensed it under their QPL (better, but not actually very good, because it's not GPL-compatible), then they licensed it under the GPL, but only for Linux, and then, finally, they released Qt4 under the GPL for all platforms.

      And now that the KDE free Qt organization is there, it means that it goes under the BSD licence if they stop developing. The only reason I brought it up is as an example of a good end of a bad situation.

      So next time, don't assume a person is trolling based on what you feel is a possible implication. Besides, KDE Free QT Foundation is what it's called! How is that ambiguous?

    63. Re:Browser-based OS by wanderingknight · · Score: 1

      I know, I know! Let's call it an "Operating System"!

    64. Re:Browser-based OS by Tangent128 · · Score: 1

      I mostly agree, but for most uses I prefer Google Earth over Maps.

      I don't expect it to be terribly long before Google Earth can run in a (non-IE) browser, though. The basic tech is all there; they just need to get Javascript and the Canvas optimized so that it works at a non-widget size.

    65. Re:Browser-based OS by cytg.net · · Score: 1

      "Honestly, if you are going to argue the point, at least think about your arguments first."

      Honestly you shoulda skipped the submit button on that one. Honestly. (and perhaps you would have had you thought it through)
      theres plenty of constructs around to do the same, like webstart, fast and reliable.

    66. Re:Browser-based OS by Tangent128 · · Score: 1

      #1 & #2 showcase another advantage of web apps: Students can use them on their personal computers without fuss.

    67. Re:Browser-based OS by Tangent128 · · Score: 1

      I'm by no means a Linux guru, but couldn't you just remove all other setuid programs and make "chroot" setuid?

    68. Re:Browser-based OS by Tangent128 · · Score: 1

      Sounds like HTML5, except for the "bare metal" part. Hmmm... maybe you could compile Firefox with Linux as a static library?

    69. Re:Browser-based OS by Eli+Gottlieb · · Score: 1

      Well that's not exactly something I can neatly package into my software, is it? It's a good way to make this work on a single Linux machine, but I can't rely on it to work as a part of a piece of software I intend to distribute.

    70. Re:Browser-based OS by kundziad · · Score: 1

      Thank you for the clarification. I may have gone too far with my praise of Microsoft. Yet still - my main point that it's not only Linux that has a network package manager is still valid.

      Offtopic: how would you compare the network software managing capabilities of Linux distributions and Windows versions? (I mean desktop applications, as that's apparently what the article is about.)

      PS: I did mention that a lot depends on the developers' implementation.

    71. Re:Browser-based OS by Anonymous Coward · · Score: 0

      #1, Yes, it is hard to push out an application to every University computer when you are at one w/ 50,000 students.

      No it's not, APT+SHH+BashScripting. You can do it with 1 command....

    72. Re:Browser-based OS by spectre_240sx · · Score: 1

      Even when it was, it was very easy to go in and see how everything ticked.

    73. Re:Browser-based OS by mjbkinx · · Score: 1

      Tamarin is under the Mozilla Tri-License. It currently only is widely distributed as part of the Flashplayer, but it will become part of Firefox and will quite possibly be available as ScreamingMonkey IE plugin.

    74. Re:Browser-based OS by Skrapion · · Score: 1

      Despite people saying how evil Javascript and web applications are, I don't see anybody refusing to use Google Maps.

      --
      The details are trivial and useless; The reasons, as always, purely human ones.
    75. Re:Browser-based OS by hotfireball · · Score: 1

      He is probably talking the hell that there is no Ajax technique in upcoming Web 3.0, since Ajax is not any new technology itself, but just wrapped HTTP request/response in background that also has a number of problems and will be unstable Beta forever due to no standards in real-world (read business world) as they do depends on how browsers implements them actually...

      In Web 3.0 there is Java Swing, JavaFX, Adobe AIR, Adobe Flash and Microsoft Silverlight. But there is no any AJax...

    76. Re:Browser-based OS by kgdoom · · Score: 1

      It's true that it's less powerful, but it doesn't matter because the ease of use gained from having the apps and the data "out there" will vastly outweigh the lack of capability for the majority of users.

      Only in the long term. Short term, my iPod doesn't have a Wi-Fi card, and the only way to get music on it is via USB directly through the OS. So you're not going to see a web based iTunes for a reason. We may be heading towards the cloud, but there are absolutely cases where "out there" does not vastly outweigh capabilities for even the most common of scenarios.

      On another note, consider the struggles of monetizing the cloud? Unless you want to pay monthly fees for storage, your data isn't going to fit fit. Beyond that, you should also consider security and lag.

      The desktop will still be relevant for a long long time because it still offers practical solutions to everyday problems. Maybe we just notice these things less because the desktop needs an overhaul (see Adobe AIR).

    77. Re:Browser-based OS by dbIII · · Score: 2, Insightful
      The Qt thing was because all of the other non GPL free licences (MIT, BSD etc) had far more of a following so it would have been a much more difficult fight. It was a very embarrassing time for free software but at least we got gnome out of it. The most embarassing thing was the ill feeling that existed long after Qt changed to GPL.

      I lost nearly all respect for RMS after that and the LiGnuX (later gnu/linux) renaming thing. Surely spreading the message to the unconverted is better than bickering with the converted?

    78. Re:Browser-based OS by Unoti · · Score: 1

      If your sysadmins were worth a damn it wouldn't matter if you needed to push updates to 5 computers or 50,000.

      You're basically right. The problem is-- and you would know this if you had ever actually done it instead of just talking smack about it-- it'll fail on some portion of the deployments, say 0.5% or 2%. Or maybe the install will go fine, but you have problems on updates. Silly things, like one user installs it, then another user runs the update, and some people have admin privileges on the machine and some don't.

      The problem is that you're only basically right about it being easy. And it's that tiny fraction of the time when it doesn't work out right that will suck up all your support time.

    79. Re:Browser-based OS by mcrbids · · Score: 1

      You are forgetting that an "application" is not the same as a word processor. Yes, a word processor is an application, but so is a CRM system, an inventory system, an insurance policy tracking system, and a registration system. These are all applications, too, and these are applications that are intensely well suited to web-based development.

      See, when you want to sign your kid up for a soccer team, you don't want to "install an application", you just want to submit your name, address, kids' name, and maybe a login/password, and be done. The idea that you should install something to sign up for a soccer team is just absurd. Yet it is a very real-world "application" that manages real data in a meaningful way, reducing costs and headaches for your local area recreation district and its member families.

      Just as nails aren't always the most appropriate fastener, web-based applications aren't ideal in all cases, either. But anytime you have to coordinate information across a distance or a large number of people in near-real-time, or deal with a large number of users with minimal interaction, you find an ideal problem for which a web-based solution is probably ideal.

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    80. Re:Browser-based OS by kjots · · Score: 0, Flamebait

      Clearly you have never done any sysadmin work.

      I'm surprised you have the balls to post such garbage using your screen name. You might as well hold up a big poster saying "I'm mweather and I'm a clueless dickhead".

      Idiot.

    81. Re:Browser-based OS by Unoti · · Score: 1

      Awesome! And true. Now, what if some of your users are on Macs and Windows?

    82. Re:Browser-based OS by lena_10326 · · Score: 1

      I suppose.. you've never read any discussions or debates on thin client versus fat client, which is essentially a 30-40 year old discussion.

      Remember telnet and terminal clients? Well, a browser is essentially the same thing. They're both thin clients and there are many pros to using them. http://en.wikipedia.org/wiki/Thin_client#Advantages_of_thin_clients

      Of course a browser serving plain HTML/XHTML is about as thin as it can get, and adding AJAX/Flash/Plugin functionality makes that client thicker, but adopting a negative stance on the basis that it's done in the browser is ridiculous, because the function and purpose of the browser is to be a thin client (since the adoption of CGI and dynamic page serving that is).

      Don't say it's bad just because you have some beef with browsers, or thin clients in general, or that the technologies are still immature. Desktop apps were pretty immature in the 1980's as well. Don't expect the progression of web based thin clients to be any different. Thin clients have a purpose and will continue to thrive, particularly on the web.

      There's a very good reason why the direction of these thin clients has a foundation on the web--because HTTP is ubiquitous. Every modern machine is guaranteed to have a browser capable of running these web apps, so obviously thin clients are going trend toward using web technologies.

      If you're going to argue against web apps, you'd be better off specifying which apps or category of apps should not be web apps. You certainly won't get anywhere arguing against them in entirety, because history has clearly shown thin clients have a rightful place within software development.

      --
      Camping on quad since 1996.
    83. Re:Browser-based OS by lena_10326 · · Score: 1

      In practice, it has not been quite that simple. For one, standard web interfaces have lack-luster and incomplete widget choices. And, different browsers support JS/DOM differently.

      X Windows had incomplete widget choices and libraries were written to develop more complex widgets. It's the same with Javascript/CSS. HTML has few widgets, but libraries have been written in Javascript/CSS to develop more complex widgets. If it's OK for one, then it's OK for the other.

      Browsers not adhering to standards is a problem, but we can't fault the standards because browser developers fail to implement them faithfully. The only time we can fault standards is when they are ambiguous, ignore current practices, prevent extensibility, or are just plain tedious, confusing or illogical.

      --
      Camping on quad since 1996.
    84. Re:Browser-based OS by Anonymous Coward · · Score: 0

      The clever thing about the web platform, and what sets it apart from other platforms, is that the security model by default lets you run any app, even one you don't trust, on any system, without it causing major catastrophes.

      BWAHAHAHAHAHAHAH! ...arf.

      (wipes coffee from face)

      Just to remind you: most of these "major catastrophes" nowadays do occur in the context of active Web content.

    85. Re:Browser-based OS by ericfitz · · Score: 1

      Web Applications are optimized for Rapid Application Development.

      Yep. Nothing says "Rapid Application Development" quite like "C". Except maybe assembly. Maybe I will build an AssemblyScript engine for web pages. Yeah, that's the ticket. Forget all this low-level AJAX stuff.

    86. Re:Browser-based OS by Anonymous Coward · · Score: 0

      #1, Yes, it is hard to push out an application to every University computer when you are at one w/ 50,000 students.

      That's an opportunity. 50k students trained to update their own bloody application on time. And if they can't, honest to god that's the least of that university's problems.

    87. Re:Browser-based OS by xalorous · · Score: 1

      Umm, yeah. The guy what's doin the development sorta works for Adobe. So, umm, yeah, he's sorta out of choices.

      --
      TANSTAAFL GIGO Acronyms to live by!
    88. Re:Browser-based OS by xalorous · · Score: 1

      Oh, puhlease. Like there's a University out there with 100% of all computers on one OS.

      I'll go out on a limb and say that any organization with 50k computers will have at least 3 OS's present. 2 guaranteed, since even the most devoted Windows shop will have 2003 server and XP Pro. Plus there will likely be those legacy Win2k servers hanging around. Oh, and the VIP's will have the latest gadgetry with Vista. And one of the guys down in the IT shop will be running linux on *something*.

      At a large University, you'll have Windows on the computer room computers, Linux, UNIX and windows on the servers, and UNIX on workstations (read graphics and modelling machines).

      Pushing out one application to any number of copies of equally patched single OS is easy. You won't find that situation in the real world.

      --
      TANSTAAFL GIGO Acronyms to live by!
    89. Re:Browser-based OS by a_claudiu · · Score: 1

      I find it strange to say the web applications are easier to write. My main problems are (but not limited to):

      1. How to handle back, forward, open in new window/tab.
      2. No log on the client side to find out what the user really did (or to see the Javascript log)
      3. Writing tones of JS (even with libraries and frameworks) for having functionalities that are granted to the desktop applications (popups with more than 2 choises, right click, clipboard ...).
      4. Different browsers.

      All the problems are solvable more or less but saying that a web application is easier to write I find it a little bit exaggerated.

    90. Re:Browser-based OS by euice · · Score: 1

      Then, I guess, we're on the same page and I misinterpreted your post.

    91. Re:Browser-based OS by jgrahn · · Score: 1

      Linux doesn't work well in the business world for ordinary users. Trust me. It doesn't. They need stuff that is windows only.

      At some point these people will have to do something about vendor lock-in ...

      Anyway, the grandparent wasn't suggesting that everybody should move to Linux. He suggested that if you have a sensible way of installing and updating installed software (using Linux package managers as an example) one of the often cited reasons for using crappy web apps goes away.

      Then there's the third option: having the admins keep software installed in one copy (or one per OS and architecture) on a central file server, on a file system which everyone mounts. This has worked nicely since Sun invented NFS twenty years ago, and I cannot see why so many people refuse to use it today. Or does Windows prevent this too?

    92. Re:Browser-based OS by SineWave · · Score: 1

      What about a beowulf of them?

    93. Re:Browser-based OS by Keeper+Of+Keys · · Score: 1

      Web apps honestly aren't much better... they usually tie you to a specific version of IE (activex) or Java

      You're behind the times. Future-looking web apps will be designed work on Firefox, will probably also work on other standards-compliant browsers such as Opera and Safari, and IE will be playing catch-up. You won't be tied to a specific OS or plugin.

    94. Re:Browser-based OS by Keeper+Of+Keys · · Score: 1

      What if your office runs Windows, Mac OS X, Symbian OS, Debian, Plan 9, Red Hat, MS-DOS and OpenBSD?

      You're fucked either way. Ever tried developing a complex web app that runs on even 7 out of the 8 of the above?

      If I was asked to develop one, I'd just make sure it worked in Opera. The poor sod on MS-DOS would be SOL, but everyone else is smiling. (Actually I'd make it work in Firefox too, but by coding to standards and not using anything too leading-edge that would most likely just happen.)

    95. Re:Browser-based OS by Jesus_666 · · Score: 1

      They will also incorporate DWIM, use Google to perfectly translate themselves into any language the user wishes and debug themselves.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    96. Re:Browser-based OS by Cozminsky · · Score: 1

      The problem is it's really insecure. You've got two choices of delegating authority for an X server. One is host based (i.e. xhosts +somehost) which will mean that rogue clients launched by that host will have access to draw anything on your screen. The second is cookie based which can probably be controlled in a more granular manner but still allows a client with the MIT-MAGIC-COOKIE-1 to write anything to a given server. The potential for keylogging, spoofing windows and other nefarious behaviour is frightening.

    97. Re:Browser-based OS by Jesus_666 · · Score: 1

      Actually, why do we bother with operating systems? We just build a SOC that runs Gecko and have the OS be an instance of Firefox, loaded from an EEPROM. Since everything is better when executed on a server we can save money by cutting down on the client hardware - after all, a web browser only needs that much power; a 1 GHz singlecore with 512 MiB of RAM should suffice. The telcos just need to stop skimping on bandwidth and give everyone 10 Gbps down/100 Mbps up and we can even play video games.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    98. Re:Browser-based OS by Anonymous Coward · · Score: 0
      So you've got users running Plan 9 on the desktop?

      .

      Thought not - and what apps do they run in common?

      Dipstick.

    99. Re:Browser-based OS by Keeper+Of+Keys · · Score: 1

      No, seriously. Who but a fool would start writing a web app that only works on IE these days?

      FYI I think DWIM support is slated for Firefox 5 ;-)

    100. Re:Browser-based OS by xtracto · · Score: 1

      I think the main problem with "web applications" is the fact that they are being developed over the most completely incorrect protocol, that is HTTP.

      What is needed is a new standard protocol, client manager (something like a web browser but conceived with the specific aim of web applications) and a set standards for interaction.

      Maybe the framework that Adobe is doing is going that way. Maybe XUL could be used for that. But what is certain is that HTTP has been oversued and raped until it has nothing more to give now.

      --
      Ubuntu is an African word meaning 'I can't configure Debian'
    101. Re:Browser-based OS by master_p · · Score: 1

      How about native apps that are lazily downloaded?

      module imports from the web?

      lazy linking?

      automatic updates at link time?

      Come on people, where is your imagination? the GP post is correct...web apps running inside a browser is a silly thing.

    102. Re:Browser-based OS by master_p · · Score: 1

      But you don't need that with a modular system that does updates lazily and on linking time. The effect is the same as the browser (publish once, run everywhere), without the constraints of the browser.

      The data can still live in the cloud...

    103. Re:Browser-based OS by Jesus_666 · · Score: 1

      Future web-apps will be written for a mishmash of platforms; (X)HTML+JS, XUL+JS, pure JS (see Objective-J), Prism, AIR, Silverlight, Flash... All of these will be more of less compatible with whatever you're running. Prism and XUL-based apps will never run on anything but Firefox. Silverlight apps will always run best under Windows. Flash will always lag behind on Linux. And so on.

      There's too many big players who want their slice of the pie. I'd say that own-runtime technologies like AIR, Silverlight and Flash will fight for the crown with (X)HTML + Javascript. And of course every browser will have its own rendering standards which will mean that we still have to be careful about which parts of CSS we use.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    104. Re:Browser-based OS by peragrin · · Score: 1

      wouldn't setting firefox as the window manager in X be easier?

      --
      i thought once I was found, but it was only a dream.
    105. Re:Browser-based OS by Keeper+Of+Keys · · Score: 1

      Sigh. I suppose you're right. Personally I would stick with slightly-less-than-cutting-edge XHTML, CSS and JS if possible, but some people are stupid enough to clutter up their app with browser-specific stuff, despite the problems it's caused in the past. Once AIR is involved, I'm not sure it really qualifies as a web app as such, more a hybrid desktop/web app.

      I think my original point is sound, though: Firefox will be the assumed foundation for most web apps because it's open, cross-platform and sufficiently advanced for most needs.

    106. Re:Browser-based OS by BountyX · · Score: 1

      I concur, Qt is the best approach in my opinion. When you think of how the moc process works vs a virtual machine, it's clear that the extra 10 minutes it takes to compile on another platform outweighs the slow VM interpretation and security issues. Web platform is hardly consistent. People just want to access their information on any terminal fast and secure...the solution is not adding new browser technology or standardizations, the solution is applications should store information on accessible servers (like direct connection to a remote MySql - dont flame me for security, its an example). As far as the security structure...since the information lives on the internet the application can be run in the user's home path, providing a secure execution that does not require a million permissions. Standard application development should also consider other server side storing facilities like sessions. So essentially you have 'customized browsers' instead of a single browser to access all information on the internet. The benefit, you get the internet model plus the power of native apps. I think 'browsers' such as Google Earth and Northwind are perfect examples of this ideology.

      --
      Trying to install linux on my microwave, but keep getting a kernel panic...
    107. Re:Browser-based OS by BountyX · · Score: 1

      Yup, that's right. The data can still live in the cloud. What we have is a lack of a good direct remote database structure for applications offered to typical developers in the way that mySql and others are offered to web developers... What were talking about is the next step beyond the web. Applications that are integrated online like Google Earth make more sense than sticking everything in a browser. Application developers are falling behind...all applications should make use of online storage facilities to some extent. It should at least be a standardized option.

      --
      Trying to install linux on my microwave, but keep getting a kernel panic...
    108. Re:Browser-based OS by trolltalk.com · · Score: 1

      I read the article. It does a translation between c and actionscript ....

    109. Re:Browser-based OS by Anonymous Coward · · Score: 0

      As for "your horrid mishmash of technologies" statement, I agree that AJAX is overused, but believe me it is very nice to be able to do stuff on the server side (think form validation), and then not have to redo on the client-side in javascript.

      I'm not sure where you got this idea, but you can definitely do form validation server side without Ajax. MVCs have been attacking this problem for years.

    110. Re:Browser-based OS by Jesus_666 · · Score: 1

      It's certainly the most likely browser to be tested against; I agree with that. On the mobile market it might still play second fiddle to Opera, but for desktops Firefox is a likely baseline.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    111. Re:Browser-based OS by Anonymous Coward · · Score: 0

      Instead of updating every computer in the office with a new version of some data management app, it is deployed once.

      Some people use (quite successfully) a shared folder on the server and a shortcut on every client machine.

    112. Re:Browser-based OS by zaphle · · Score: 1

      Off-line support is only necessary as a short-term stopgap until the cloud is visible again ...

      Consider the following:

      1) In order to get online on the web cloud, I need an internet connection. Without it, I can't access my data, while others can. If for some reason I can't pay for my internet connection, I can no longer access my data. Where I live, the internet providers basically have an oligopoly (near-monopoly) since there are only 2 of them (sure, there are others, but they depend on the prices of the 2 major ones). This makes me highly dependent.

      2) When I create content with sensitive data about private issues (e.g. you want to solicit for another job), this data has to travel over the line even when all I want to do is save a draft version of a document that I may decide to delete later on. Knowing that such data can be easily read by third parties when transferred over the internet, I personally rather restrict the times that I send data over the internet to a minimum.

      To conclude, the web platform as an operating system makes you financially more dependent and is a threat to privacy. But feel free to join, I know I won't.

      --
      And what if there's nothing behind the door until it is being opened?
    113. Re:Browser-based OS by zaphle · · Score: 1

      ... but believe me it is very nice to be able to do stuff on the server side (think form validation), and then not have to redo on the client-side in javascript.

      Frankly, you should be doing everything on the server side.

      If you're going to do everything (validation too) server-side, your application will be very slow and not user-friendly. In fact, a good web-application should do things like validation twice: once in javascript/AJAX and on submit again on the serverside for security reasons. This is why writing good validation in web-applications is far more difficult to maintain than in ordinary windows-based applications: there's a need for redundant checking because you pass everything over a non-secured protocol (http) that can be easily mimicked by hackers who want to push invalid data into your system.

      --
      And what if there's nothing behind the door until it is being opened?
    114. Re:Browser-based OS by huckamania · · Score: 1

      I'll take a guess...

      Hmmm, um, I know, I know, someone who works in a windows shop? Is that the answer?

      A friend had me do a small web app for his sales team and he didn't care at all about FF support. He wanted to do it in ajax or something but I convinced him to use PHP, mysql and Apache. I tested using IE, but I know it also worked in FF.

    115. Re:Browser-based OS by SanityInAnarchy · · Score: 1

      A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers.

      However, many browsers are portable themselves, and it is possible to make a cross-browser toolkit.

      What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time.

      Except that if you're going to compile it for every platform, then everyone who builds such an app will compile it for the platform they need, and ignore the platforms they don't. Web apps, being interpreted, are more automatically portable.

      And these are not the only advantages.

      They're slow, crappy, and often insecure.

      Slow -- not significantly slower than a desktop app, as far as the user knows. Very few apps actually need to be faster than a web app.

      Crappy and often insecure -- well, many of them, I suppose. That's not the fault of the platform. It is possible to build excellent, secure web apps, as Gmail proves. (If you didn't know, https://mail.google.com/)

      --
      Don't thank God, thank a doctor!
    116. Re:Browser-based OS by Tablizer · · Score: 1

      X Windows had incomplete widget choices and libraries were written to develop more complex widgets.

      X-Windows doesn't work well in HTTP environments because it does not handle latency well. For example, you usually don't want the server to process every keystroke, but rather only examine form contents when a form is submitted or some pre-specified event (on-change-focus, etc.) X-Windows is too low-level in this regard.

      but libraries have been written in Javascript/CSS to develop more complex widgets.

      I've been unimpressed. If you spend a lot of money you may be able to get decent widgets, but even these tend to have version problems, especially if you don't keep shelling out money for updates as new browser versions come by.
         

    117. Re:Browser-based OS by Lodragandraoidh · · Score: 1

      You took the words right out of my mouth.

      This, of course, would be a monumental undertaking -- basically creating a security access tunable virtual window into multiple OSs with a consistent display of graphical user interface with full multimedia capabilities worthy of building quality simulations/games - in addition to your standard office type applications and persistence capabilities. This would take a large team to build, with the expectation that it would be used as a framework by large numbers of developers; the W3C's view of these kinds of capabilities is only in its infancy - via the Web Applications Working Group, and what is there looks less ambitious than we are talking about here.

      --

      Lodragan Draoidh
      The more you explain it, the more I don't understand it. - Mark Twain
    118. Re:Browser-based OS by Anonymous Coward · · Score: 0

      'At some point these people will have to do something about vendor lock-in ... '

      How do they do that; instead of paying a license for 5000$ they need to pay 500000$ to develop the same software that works on linux ?
      Or do they wait for another compny to do it ?
      Or they manage to gather all the other software users and work together happily together ? (yeah right..)
      Then they have to get the project open source (or what wouldit change)
      That is the known problem of specific program in the GPL world:
      who wants to pay for it....when everyone will get it for free after.

    119. Re:Browser-based OS by V+for+Vendetta · · Score: 1

      I don't know why this got modded "Insightful"

      I do agree that native applications are nicer than web applications [...] However what we have discovered is that (1) web applications are easier to write, [...]

      We as developers shouldn't think about the ease of coding, but the ease of usage. You had it right in your first sentence. Web apps are fine for "once a day, five minute" kind of jobs. Or administrative tools like a web interface to a router, for example, where you spend 2 hours once to configure it and afterwards seldom touch it again. But that business app, that is used 8 hours a day, is a PITA for a user if it's a web app. We serve the user, not the other way around.

    120. Re:Browser-based OS by lena_10326 · · Score: 2, Informative

      X-Windows doesn't work well in HTTP environments because it does not handle latency well.

      While I understand your point, I don't know why you mentioned it. A low level correlation was not what I intended. I was speaking high level.

      If you spend a lot of money you may be able to get decent widgets

      There are tons of free frameworks and one off widgets. http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks

      For some, you do still have to style them a little to fit within your page design if you want a seamless look, but for the rest they work fine unmodified. Just drop them right in place and change a few text fields.

      --
      Camping on quad since 1996.
    121. Re:Browser-based OS by bestinshow · · Score: 1

      Lots of business applications are about data collection and presentation. If there's anything the web is good at it is presentation of content in a very simple and easy manner that is (a) easy to code and (b) easy to use.

      Even simple data acquisition applications are good for online applications, anything that can fit in a form based approach for example, and are just as simple to use as a VB application, but it'll run on the Macs and Unix boxes in use around the company as well, whilst not requiring local installation, it's just a link on the intranet.

      Online replacements for Office? No, not going to happen, they're all crap at the moment, they're worse than Write for Windows 3.1 (mainly due to lacking fast native canvas elements). Outlook replacement? Yeah, that's far more limited in structure, is mostly about presentation, and Outlook is rather dire anyway.

    122. Re:Browser-based OS by Eli+Gottlieb · · Score: 1

      What if you use Xephyr? Then, I would think, even if something takes over your screen it can only capture input to one window and only draw on one window.

    123. Re:Browser-based OS by atraintocry · · Score: 1

      The biggest problem I have with Windows Installer packages is when you edit values in the package, and the package installs normally, as if you hadn't made the changes. Or something works once (let's say, a value to disable auto-update) which is then broken during the next release, without warning. I've never seen Adobe Reader or the JRE install the way I am expecting them to. No matter what, you still end up screwing with individual registry entries on the workstations.

      You probably already know this, but you can do a lot with Orca, the MS tool, and sometimes this means you don't have to screw with the custom transform apps.

      I get the feeling that MSI is purposely limited because people who need really robust software management for Windows are pushed to buy Systems Management Server. This annoys the crap out of me -- only Microsoft could ship a server OS without decent management tools, then charge an extra thousand dollars for the tools, and not get called out for it.

    124. Re:Browser-based OS by Anonymous Coward · · Score: 0

      #1, Yes, it is hard to push out an application to every University computer when you are at one w/ 50,000 students.

      Well the solution is obvious, you need to be at one with everything.

    125. Re:Browser-based OS by mseidl · · Score: 1
      Wait till someone throws in:

      int main(){while(1){malloc(1);}return 0;}

    126. Re:Browser-based OS by atraintocry · · Score: 1

      *All* applications are about data collection and presentation. But for something like a CRM, you have to be able to work quickly. Web apps are OK for calendaring, but when you're taking somebody's order over the phone and need to work fast, they don't hold up.

      That's not saying they won't get there though, even within a year. Just thinking of my own users' requirements, I think the biggest problem with the browser is that it steals a lot of good keyboard shortcuts. Lots of business still use terminal apps that make heavy use of F-keys.

    127. Re:Browser-based OS by atraintocry · · Score: 1

      Whoops...I just realized that the web page can take back control of the F-keys. Nice to know.

    128. Re:Browser-based OS by V+for+Vendetta · · Score: 1

      Even simple data acquisition applications are good for online applications, anything that can fit in a form based approach for example, and are just as simple to use as a VB application [...]

      No, they're not. Because they're not fast enough. We're still using an old DOS application in our company. Wathcing the people using this application is amazing. They know this application so well, that they're able to key in stuff in advance, without the need to look at the screen. Due to the DOS inherent keyboard buffering, their speed's amazing. It will take a long time until browser based applications can provide such a speed.

      Yes, presentation is fine with a browser, but that's really it. We have tons of web based applications. And while in theory they should have no prerequisits than a browser, reality is different. App A requires IE6, app B Java x.x while app C requires Java y.y while app D needs popups enabled. So, while you don't have to install the application itself on the workstation, you only exchanged that for installing (and keeping current) the foundation for all those web apps.

    129. Re:Browser-based OS by Chester+K · · Score: 1

      Native programs are optimized for speed, Web Applications are optimized for Rapid Application Development

      I think you're confusing Rapid Application Deployment with Rapid Application Development. There's nothing that's any more rapid about web app development than there is about traditional client development; in fact the tooling for traditional client app development is much better (as it's had a two decade head start).

      --

      NO CARRIER
    130. Re:Browser-based OS by JebusIsLord · · Score: 1

      I'm not behind the times, I work in a real industry (almost all of which are, as you said, behind the times).

      --
      Jeremy
    131. Re:Browser-based OS by Anonymous Coward · · Score: 0

      recalcitrant

    132. Re:Browser-based OS by Tablizer · · Score: 1

      There are tons of free frameworks and one off widgets. ... Comparison_of_JavaScript_frameworks

      I tried some of the data grid/sheet widgets, and they are either lacking features and/or have odd behavior. They are not "ripe" yet. Maybe in a few years they'll be ready.
             

    133. Re:Browser-based OS by Keeper+Of+Keys · · Score: 1

      I hope you're advising your employers to take a standards-based approach to any future web apps?

    134. Re:Browser-based OS by bill_kress · · Score: 1

      Oh, I totally agree that we need embedded apps. My disagreement was with someone who said they didn't believe in ANY browser apps, I think that's really cutting yourself off at the knees--just like it would be to go 100% browser right now.

    135. Re:Browser-based OS by edittard · · Score: 1

      The normal excuse for not reading the summary is that usually it bears no relation to the article anyway.

      --
      At the bottom of the /. main page it says 'Yesterday's News'. Well they got that right.
    136. Re:Browser-based OS by jesser · · Score: 1

      If it requires Java, it's not a web app.

      --
      The shareholder is always right.
  2. Meet the new boss by vivaoporto · · Score: 4, Funny

    Same as the old boss.

    1. Re:Meet the new boss by Anonymous Coward · · Score: 0

      You mean:

      Meet the new boss, same as the old JBoss

  3. And once we have C... by Anonymous Coward · · Score: 5, Funny

    We can write PHP! And then browser security will be top notch.

    1. Re:And once we have C... by rrohbeck · · Score: 1

      Meh.
      But we can have Perl running in the browser, finally.

  4. Sound and Music? by malfist · · Score: 0

    Is it just me but isn't music also sound effects?

    1. Re:Sound and Music? by 2nd+Post! · · Score: 4, Informative

      Nope. SFX is generally event driven (hit a key, hear the sword swing) where music is not (enter an area and music plays continuously in the background).

      SFX requires timing, latency, and speed to be accurate. Music requires bandwidth and a minimum level of continuous CPU cycles.

      Both have different needs so you can have one without the other (when you are talking emulation).

    2. Re:Sound and Music? by Anonymous Coward · · Score: 0

      Not to get too off topic, but no. There are different mechanisms in an average game engine to constantly stream a sound (i.e. music) and to do event based, often environment affected sound (sound effects).

  5. what? by thermian · · Score: 5, Funny

    You mean my preferred language has just become cool?

    Ok, this is either great news or the world is about to end.

    I think I'll go stand in a doorway for an hour or two, just to be on the safe side.

    --
    A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
    1. Re:what? by eviloverlordx · · Score: 5, Funny

      I heard that COBOL is next on the TODO list.

      --
      'Loose' is when your pants are three sizes too big. 'Lose' is when you misuse 'loose'.
    2. Re:what? by dgatwood · · Score: 4, Interesting

      I'd use C for everything if its string handling weren't so utterly broken. It makes sense from a pure performance, near-the-hardware perspective to handle strings the way it does, but what is desperately needed is POSIX standardization of stracat/stracpy. That one change would make it trivial to eliminate 99% of all buffer overflows in typical apps (and, ideally, kernel code)....

      char *stracpy(char *src) Returns a copy of a string in a newly allocated buffer large enough to hold the result. char *stracat(char *string1, char *string2 ...) Returns a newly allocated string that contains the concatenation of two or more strings.

      Sure, I could write my own, and pretty much everybody on the planet has done it at least once in their lives, but it seems ridiculous that such obvious operations require hand holding. Outside of embedded platforms where malloc is expensive, dynamically allocating a new buffer for concatenations should be the norm. For situations where performance takes a big hit because you can't afford to copy the source string every time, you could also add this API:

      strbuf_t strbufalloc(char *src [, size_t size_hint]) Returns a copy of a string in a newly allocated buffer large enough to hold the result. The optional second parameter size_hint allows you to specify a suggested size for the buffer. strbuf *strbufcat(strbuf_t string1, strbuf_t string2 ...) Returns a newly allocated string that contains the concatenation of two or more strings. The value of string1 must be a string buffer (strbuf_t). The value of string2 may be either a strbuf_t or char **.

      Wherein strbuf is opaquely defined as:

      struct strbuf_private {
      char *content; // null-terminated string
      size_t length;
      void *private_history_data;
      };

      struct strbuf;
      typedef struct strbuf *strbuf_t;

      and the routines automatically realloc the internal char * buffer as needed to grow the size to hold incoming content and likely future content based on historical data about prior operations on the structure, the algorithm for which would be an implementation detail outside the scope of the standard. That said, for the rare cases where a simple copy hurts performance badly enough for most folks to care, chances are your application knows its own growth policy better than the OS could guess anyway, so you probably should just roll your own buffer management code. The important bits to add to the standard are those first two functions (stracpy and stracat).

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    3. Re:what? by Anonymous Coward · · Score: 0

      Also, may I just say that wow, the Slashdot CSS for dl/dt/dd is broken horribly....

    4. Re:what? by Anonymous Coward · · Score: 0

      if they announce turbo pascal is next, i'm gonna shit.

    5. Re:what? by Anonymous Coward · · Score: 0

      I heard that COBOL is next on the TODO list.

      Ha.

    6. Re:what? by Anonymous Coward · · Score: 0

      Some posts up, someone wrote "Er, disregard that, I was wrong" and got modded "+3 Informative". This here has been ignored, at least until this moment. Go figure.

    7. Re:what? by cripkd · · Score: 1

      Do you accept coupons for this crash course in C?
      Also, is paypal ok? :)

      --
      Curiously yours, crip.
    8. Re:what? by naasking · · Score: 4, Informative

      See The Better String Library. Haven't used it myself, but it's supposedly very portable, high performance, and has good interoperability with normal null terminated C strings.

    9. Re:what? by cripkd · · Score: 1

      I finished implementing COBOL in Tamarin around february, you're so last year.
      I'm looking for a fast desk-top scanner that accepts batches of 100 punch cards so that I can implement that in browsers. That would e way cooler that Quake. I will do basic math !!!

      --
      Curiously yours, crip.
    10. Re:what? by swanriversean · · Score: 1

      bstring is really nice to use ...
      that is the thing about C (and C++) ... for almost any complaint you have about the language lacking something or another, there is a library (usually open source, and usually under a commercial-friendly license too)
      and with C, if you don't need it, you don't have to worry about it showing up at runtime anyway and slowing you down ... all this beautiful hardware, all this so-slow code ... there are times and places for any language, but I think too many can't even recognized the time or place for C (and C++) anymore

      --
      Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seus
    11. Re:what? by irtza · · Score: 1

      While I agree the addition of these functions would be very useful, and having a standardized way to do it in posix would simplify things greatly, you must also realize that this method is a tradeoff. Whenever C routines automatically allocate a new buffer, someone had better free() it later. You solve the buffer overflow problem and replace it with a memory leak. Any argument to the point of "make sure you track pointers" or "most programs don't run long enough for this to matter" can be as dangerous as "you should check the data before copying it into a buffer". This is why high level languages exist. They take away a lot of the menial tasks that C doesn't handle. Its a trade off of control/power/performance for ease of programming/code maintenance/reduced bugs. Most of my programming is done in C, but that is because of my own comfort with the language. I learned it growing up, and I feel more comfortable with it. I am not a professional programmer, so learning more programming languages isn't really what interests me (I do know java and basic, but have a harder time accomplishing my goals with those). Since garbage collection is so closely tied with the system itself, implementing an automatic one in C properly seems a bit difficult (though it should be a bit easier in C++ since you can create a list to track new allocations and overide the assignment variable to add each eassigned variable to the list of things "pointing to an allocation" and delist what it was pointing at.) Looking at this post, I realize I should have hit "enter" at some point... oh well.

      --
      When all else fails, try.
    12. Re:what? by Ant+P. · · Score: 1

      Sounds like you want D.

    13. Re:what? by Per+Wigren · · Score: 1

      Not pure COBOL, though. It's COBOL ON COGS.

      --
      My other account has a 3-digit UID.
    14. Re:what? by dgatwood · · Score: 1

      Whenever C routines automatically allocate a new buffer, someone had better free() it later. You solve the buffer overflow problem and replace it with a memory leak.

      Only if you do something particularly sloppy. In the case of the concatenation, the only thing you could possibly leak that you wouldn't otherwise leak would be the first argument, and the common usage would probably be char *strc = stracat(stra, strb); free(stra); or similar. For that matter, you could add a third function, char *stracatfree(char *, char*) that did both at once that you could use if you know you aren't going to need the first value again.

      Besides, memory leaks are easily found through trivial testing techniques. Memory always leaks for a substantial percentage of the executions of a function if it is going to leak at all. The exceptions are pretty rare. Even for the rare cases, though, there are plenty of tools that make it easier to find them. Buffer overflows, however, are a pain in the backside to find and fix (particularly when they stomp on a pointer, which in turn causes some other piece of code elsewhere in the app to stomp on a completely unrelated piece of memory), and are far more likely to be found by somebody through accidentally stumbling across it than through any meaningful testing process.... Given a choice, I'd take a million memory leaks over one buffer overflow.

      I mean, I can tell you how much memory leaked by doing something like this (WARNING: not thoroughly tested code):

      #include <stdlib.h>
      #include <sys/types.h>
      #include <stdio.h>

      size_t global_leak_counter = 0;

      void *countmalloc(size_t a) { void *ret = malloc(a + sizeof(size_t)); global_leak_counter+= (a); *(size_t *)ret = global_leak_counter; return ret+sizeof(size_t); }
      void countfree(void *a) { void *x = a-sizeof(size_t); global_leak_counter -= *(size_t *)x; }

      #define malloc(a) countmalloc(a)
      #define free(a) countfree(a)


      int main(int argc, char *argv[])
      {
      char *x = malloc(4);
      char *y = malloc(13);

      fprintf(stderr, "Size: %zu bytes\n", global_leak_counter);

      free(x);

      fprintf(stderr, "Leaked %zu bytes\n", global_leak_counter);
      }

      Usually (at least outside of embedded applications) there's not much more effort needed to see if your code is going to leak like a sieve beyond doing this and running it through the major code paths. Just my $0.02.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    15. Re:what? by roothog · · Score: 1

      what is desperately needed is POSIX standardization of stracat/stracpy.

      I can't help with your first request, but doesn't strdup already do the second? OK, so I don't think it's actually POSIX, but it's in most C libraries I've ever used. Remember to call free.

    16. Re:what? by Curate · · Score: 1

      I agree that string handling is weak in the standard C library. For the most part, memory management is not combined with string operations. But those can be written easily. Sure, the standard C library can include the functions you mention, but are you sure that's enough? Everyone's going to want to do something different. For example, there's a growing needs for Unicode, in various encodings (e.g. UCS-2, UTF-8). The standard library will never be good enough for everyone, especially when needs change so fast.

      BTW, while the occasional malloc() is not disastrous, certain code that does intensive string operations would be slowed down considerably if the only string operations required memory allocations. There is a definite need for performing string operations into a given pre-allocated buffer.

      I have a couple of nits regarding your specific suggestions.

      >> char *stracpy(char *src)
      This is strdup(), already in the standard library.

      >> strbuf_t strbufalloc(char *src [, size_t size_hint])
      C doesn't have optional arguments. Maybe you are thinking of C++?

      >> strbuf *strbufcat(strbuf_t string1, strbuf_t string2 ...)
      >> The value of string2 may be either a strbuf_t or char **.
      How does the function determine which type of arg string2 is? C doesn't have function overloading. Again I ask, are you thinking of C++?

    17. Re:what? by Anonymous Coward · · Score: 0

      BASIC FTW!

    18. Re:what? by Ambiguous+Puzuma · · Score: 1

      No optional arguments in C?
      Then what purpose does stdarg.h serve?

    19. Re:what? by rrohbeck · · Score: 1

      If you have C then you have C++ too.
      No need to use the old libraries.

    20. Re:what? by irtza · · Score: 1

      While I agree that buffer overflows are more dangerous and difficult to debug, I wanted to note that the above code would fail in the case of a library function that returns preallocated code as that function would either have to be recompiled to make use of the allocation tracker or would be missed by this routine. From my understanding, there are debuggers that can replace malloc with something similar to what you propose, but on that hand there are also debuggers that can detect buffer overflows by allocating bytes beyond that returned by malloc and breaking if they are written to.... quick search yields electric fence :)

      Just a note, I certainly have written a function to allocate new memory and concatenate because it is unbelievably useful and saves a ton of code. This is all just for discussion and my education ;) (had no clue what was needed to actually allocate protected mem after a malloc).

      --
      When all else fails, try.
    21. Re:what? by TheRaven64 · · Score: 1

      POSIX contains strdup(), which does what you seem to want stracpy() to do. asprintf() hasn't made it into the standard, but it's implemented in most *NIXes.

      --
      I am TheRaven on Soylent News
    22. Re:what? by 42forty-two42 · · Score: 1

      Varargs is only usable if you can determine via some other means the types and number of your arguments.

    23. Re:what? by Pr0xY · · Score: 1

      if you want those features, why not just use c++? I know this sounds sarcastic, but to be honest, you don't HAVE to use things like objects and templates in c++. And you can gain the benefits of things like: std::string (basically handles ALL of what you just asked for and is standard). Or std::vector (resizable array), or std::list, and so forth.

      The reality is that c++ code can be just as efficient as c code when it is written well (just as in any language). And to be honest, an awful lot of c code would work just fine in a c++ compiler with little to no changes.

    24. Re:what? by 42forty-two42 · · Score: 2, Informative

      Glib has something more or less exactly like this, minus the private_history_data (what's that supposed to be for?)

    25. Re:what? by Sigg3.net · · Score: 0

      4. ???
      5. Profit!!

    26. Re:what? by springbox · · Score: 2, Insightful

      You do realize that everything you described can be written in C..

    27. Re:what? by spitzak · · Score: 1

      Your "stracpy" is actually standardized, it is called strdup().

      I'm not sure how useful the stracat one is, as most code I see strcat's in a loop, or has some if statements around some of the strings, or otherwise makes this difficult. What would have to be done instead is to make some sort of list which stores pointers to all the strings you want to concatenate. You then call a function at the end which measures all of them, and allocates and concatenates into it. I suspect most C programmers would write this themselves.

      Also for standard C the variable argument list for stracat would have to have a null terminator.

      One thing I would like to see in posix is a "is_string_constant(char*)" that returns a bool. It is true if it points to a string constant and false if it points to allocated memory or local memory on the stack. This would allow "efficient" C++ style strings that don't malloc copies of string constants, and would probably remove most of the objections of C programmers to using a string library.

    28. Re:what? by DRobson · · Score: 1

      char *stracpy(char *src) Returns a copy of a string in a newly allocated buffer large enough to hold the result.

      From man strdup:

      strdup, strndup, strdupa, strndupa - duplicate a string

      char *strdup(const char *s);

      The strdup() function returns a pointer to a new string which is a duplicate of the string s. Memory for the new string is obtained with malloc(3), and can be freed with free(3).

    29. Re:what? by Anonymous Coward · · Score: 0

      Outside of embedded platforms where malloc is expensive

      ... you can afford to use a language and runtime that don't want you to fail. Taking absurd risks to shave one or two cycles here and there is what C is for.

    30. Re:what? by Anonymous Coward · · Score: 0

      Fuck it.. Use machine code

    31. Re:what? by dgatwood · · Score: 1

      Sure that only works for explicit malloc calls. You can also do the same override tricks for any library function if you want, though. The best way, of course, is to use something like dtrace to simply snag the actual malloc and free calls and do all sorts of statistics or, as you noted, a debug malloc library that overrides the symbols at the linker level, though even that won't catch things like C++ new operators, page-sized allocations created using system-call-based allocators like vm_alloc or mmap, etc. That said, you can do a lot with dtrace in that area.

      The problem with standard malloc guard areas is that they only detect scribbling at certain key points---when you return from a function, when you do a malloc, etc.---and are way too slow to leave turned on continuously. You can't have the CPU trap on writes to any blocks smaller than an entire page, and hacking malloc() to always return page-sized blocks doesn't really detect buffer overflows unless you leave it set that way and waste a truckload of memory. Those are neat tricks to help debug things, but you still need to do fuzzing of the inputs or similar to have a prayer of catching anything with them.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    32. Re:what? by Anonymous Coward · · Score: 0

      Your strbuf implementation could be improved, by taking and returning char* instead of strbuf. This is done in libHX and allows for direct use of a variable, e.g. with printf:
      char *s = hmc_sinit("foo"); hmc_strcat(&s, "bar"); printf("%s\n", s);

    33. Re:what? by Jesus_666 · · Score: 1

      Unfortunately bstring doesn't do Unicode. While using strings in C/C++ is mostly annoying, using non-English strings in C/C++ is mostly like pulling your own teeth. Latin-1 can only take you so far (and doesn't always work).

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    34. Re:what? by jcupitt65 · · Score: 1

      GLib has what you're asking for and is available everywhere under the LGPL. You write to the GLib API, which is mostly sane, and your code will run natively on *nix and win. I believe they even support AIX.

      For example, see

      http://library.gnome.org/devel/glib/stable/glib-String-Utility-Functions.html

    35. Re:what? by Anonymous Coward · · Score: 0

      How is stracpy different to strdup?

    36. Re:what? by Anonymous Coward · · Score: 0

      The problem isn't that strcpy leads to buffer overruns and the like, it's the programmer.

      None of your solutions actually fix the problem (essentially, you're stating you want C to have garbage collection.) Even if you implement your ideas, you can still get buffer overruns in other places.

      By the way, the function names you're referring to are strcpy, strcmp, there's no 'a' in there. Any embedded project I see or have worked on uses malloc as well, typically with a custom memory manager. I'm not sure if you're just complaining for the sake of doing so, but your views and opinions of C are completely in left field.

      C is meant to be a language that sits as close to the metal as you can get and still be cross platform.

      If you can't understand the concepts of C, or if you do not wish to understand the concepts of C, you shouldn't be using it to begin with.

    37. Re:what? by Anonymous Coward · · Score: 0

      your proposal of stracpy is pretty much implemented in most of OSs available: strdup

  6. Internet-C reborn? by dyfet · · Score: 3, Interesting

    There used to be a project, many years ago, which was I believe called itself something like "Internet-C". It used gcc with a pseudo-code backend to produce portable binaries which could then be ran from a plugin or through an emulator. Since gcc was tuned for register based archectures and 68k was already an existing backend, I think the pseudo-machine code he used was based at least loosely on the 68k one.

    1. Re:Internet-C reborn? by twiddlingbits · · Score: 1

      I did some work back in the early 80's where I wrote a benchmarking algorithm in C then used gcc to generate intermediate code then ran the intermediate code thru another tool to produce binaries for X86, 68K and PowerPC architectures. It all ran under VxWorks for an OS so I didn't need an emulator and it wasn't on the bare hardware either. Pretty nifty stuff at the time, we had DoD funding to look at the performance of commercial chips versus the 1750 processor and C versus Ada. IIRC, a lot of this work helped baseline the processor and language choices for the JSF avionics suite. Stuff we got now runs rings around this.

    2. Re:Internet-C reborn? by LWATCDR · · Score: 1

      Sounds a lot like Juice.
      http://www.modulaware.com/mwolink.htm
      It was a plugin that took an intermediate code and then compiled it to run at native speed.
      Of course this worked over the internet.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    3. Re:Internet-C reborn? by LWATCDR · · Score: 3, Interesting
      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    4. Re:Internet-C reborn? by naasking · · Score: 3, Interesting

      The DotGNU project compiles C to the CLR, so that fits the bill.

  7. Right... by Colin+Smith · · Score: 1, Troll

    You realise that all the OS layers, networking layers, web browsers, scripting languages are primarily to try to get away from C?

     

    --
    Deleted
    1. Re:Right... by Anonymous Coward · · Score: 0

      And now we are free to cast them aside and return to our love of allocating our own memory.

    2. Re:Right... by Nyall · · Score: 5, Insightful

      primary? ummm... I thought the primary point of layers is so that you can do a lot with only a few simple function calls

      --
      http://en.wikipedia.org/wiki/Jury_nullification
    3. Re:Right... by HolyCrapSCOsux · · Score: 1

      How so? That's like saying sushi bars are there to try to get away from fishing.

      --
      0xB315AA8D852DCD3F3DCA578FD2E0BF88
    4. Re:Right... by Anonymous Coward · · Score: 0

      Which simply means that we can't.

    5. Re:Right... by Chris+Mattern · · Score: 5, Funny

      The circle is now complete. When C left Unix it was but the back-end. Now, it is the API.

    6. Re:Right... by gbjbaanb · · Score: 1

      yeah, and look at the mess that happens when you make a language so easy to use a web designer starts to code with it :-)

      Oh, and all those OS layers, networking layers, web browsers and scripting languages are written in C. It must have something going for it.

    7. Re:Right... by twiddlingbits · · Score: 3, Informative

      And you realize all the overhead this created? It's why we needed dual core 3GHz 64 bit processors. C code, properly written is very tight and fast. Too many layers complicates the issue and introduces more chances of error. If you are looking inside Unix you'll find out the OS is written in C (and some assembler). You can have a GUI/Windows and still have C code..it's called X/MOTIF and has been around a long time, works well and is very fast. I'm pretty sure the current Linux GUIs owe a lot to to Motif.

    8. Re:Right... by camperdave · · Score: 4, Insightful

      How so? That's like saying sushi bars are there to try to get away from fishing.

      Well, it must work because I've never had to catch a fish to eat sushi.

      --
      When our name is on the back of your car, we're behind you all the way!
    9. Re:Right... by Achoi77 · · Score: 5, Funny

      only an API of evil, Darth!

    10. Re:Right... by internerdj · · Score: 1

      Well the next step is C++ and Java. Then we can write OS layers, networking layers, web browsers, and scripting languages that run on top of OS layers, networking layers, web browsers and scripting languages because RAM is now cheap...

    11. Re:Right... by Anonymous Coward · · Score: 0

      If C strikes down Unix, Unix will become more powerful than C can possibly imagine.

    12. Re:Right... by jollyreaper · · Score: 1

      only an API of evil, Darth!

      Bill Gates: If you strike me down, I will become more powerful than you can possibly imagine.

      Stalman: I'm willing to risk it! *hum!* *slash!* *thump!*

      --
      Kwisatz Haderach
      Sell the spice to CHOAM
      This Mahdi took Shaddam's Throne
    13. Re:Right... by Colin+Smith · · Score: 1

      I thought the primary point of layers is so that you can do a lot with only a few simple function calls

      Right. So you don't have to write so much C.

       

      --
      Deleted
    14. Re:Right... by omnipresentbob · · Score: 1

      Only an API of evil, C.

    15. Re:Right... by msuarezalvarez · · Score: 4, Insightful

      I'm pretty sure the current Linux GUIs owe a lot to to Motif.

      Indeed. The violent urge to get rid of Motif has been a driving force in most of the modern GUI development.

    16. Re:Right... by Anonymous Coward · · Score: 0

      Wow, someone else has thought of the balancing of the force that I did in relation to his prophecy, or everybody just failed to mention they thought of it too...

    17. Re:Right... by spiffmastercow · · Score: 1

      I had the same thought too.. I just rarely voice it because I don't care enough about it to get in arguments with star wars fanboys.

    18. Re:Right... by bhamlin · · Score: 1

      ... The violet urge ...

      There, fixed that for ya.

  8. Adobe is almost as innovative as Microsoft by Anonymous Coward · · Score: 0

    Adobe just invented CGI! Good work, guys.

  9. Security? by Anonymous Coward · · Score: 0

    in other news, the amount of spyware-infected computers increased by 500%

  10. Where did they get the Zelda on PC? by Anonymous Coward · · Score: 4, Insightful

    Is that a pirate copy? Just curious...

    1. Re:Where did they get the Zelda on PC? by PlatyPaul · · Score: 1

      Well, according to Nintendo, it must be.

      Also feel free to check this out. It's not fantastic, but it's not bad.

      --
      Misery loves company. Online misery loves unsuspecting random strangers.
    2. Re:Where did they get the Zelda on PC? by Rob+T+Firefly · · Score: 5, Funny

      It's a secret to everyone.

    3. Re:Where did they get the Zelda on PC? by Anonymous Coward · · Score: 0

      +1

    4. Re:Where did they get the Zelda on PC? by howdoesth · · Score: 1

      So according to Nintendo, the "rightful owner of an authentic game" is entitled to have a copy to protect against damage or loss, but a Game Copying Device is inherently illegal because the copies it makes can be uploaded to the internet? Where is the legal backup copy supposed to come from? Will they give you a second cartridge if you ask nicely?

    5. Re:Where did they get the Zelda on PC? by tiananmen+tank+man · · Score: 1

      Most likely by buying the handheld console, the game and a flash cart to dump the game. Where in that process is anything illegal done?

    6. Re:Where did they get the Zelda on PC? by noidentity · · Score: 1

      There's no game called "Zelda", so it could have been homebrew. Assuming it's "The Legend of Zelda", a game by Nintendo, it could be a copy legally transferred with a NES game dumper owned by the user.

  11. Wow.. by spiffmastercow · · Score: 1

    I can't believe it.. An idea for a web programming environment that would make me hate web programming slightly less.

    1. Re:Wow.. by Anonymous Coward · · Score: 0

      You insensitive clod. Now they'll have to abandon development :(

    2. Re:Wow.. by Anonymous Coward · · Score: 0

      really? i had the complete opposite reaction

    3. Re:Wow.. by spiffmastercow · · Score: 1
      Yeah.. Finally I'll be able to use pointers again!

      Besides, ANYTHING is better than javascript.

    4. Re:Wow.. by Anonymous Coward · · Score: 0

      Besides, ANYTHING is better than javascript.

      You may want to take a look at haXe.

  12. am I the only one bored with the software world? by Anonymous Coward · · Score: 5, Insightful

    Everything's being constantly reinvented but no actual progress is being made. Oh look, the 100th toolkit to do exactly the same thing! Oh look, a new way of layering something old on something old on something old to give something new! Oh look, another silver bullet framework!

    Can anyone here remember the web of 10 years ago, for example? Content = text for reading + graphics for illustration. No bullcrap, just Google/Wikipedia style web sites to give me a simple navbar + content.

  13. But is it secure? by Animats · · Score: 4, Informative

    If the "byte array mapped to RAM" installed in Tamarin allows the code to store anywhere in the interpreter's space, that's a huge security hole. It can do anything the user process can do. If you're going to allow that, you may as well just load executable machine code directly, as with Active-X.

    Anyway, the article is a blog post that rehashes an interview from last year. The info in that article is better.

    1. Re:But is it secure? by ergo98 · · Score: 5, Insightful

      If the "byte array mapped to RAM" installed in Tamarin allows the code to store anywhere in the interpreter's space, that's a huge security hole. It can do anything the user process can do. If you're going to allow that, you may as well just load executable machine code directly, as with Active-X.

      You should email them and tell them about this! Surely they haven't though of such a thing!

      Sarcasm aside (sorry, I couldn't help myself), I suspect the VM needs to actually hand you a block of memory, and on accesses it validates that it is within the VM allocated range. Anything less would be silly, however such a thing would provide a huge win (I've tried to do image editing in pure managed code, and then found a massive performance win switching it over to P/Invoke native code).

    2. Re:But is it secure? by Yold · · Score: 1

      Exactly what I was thinking. There isn't much space to compromise between the security of Java applet, and the speed of an Active-X plug-in. So this is basically a cross-platform version of Active-X; I am sure that will make many system administrators happy, especially the ones that grant their OS X users admin rights, thinking they are safe =) from web-installed rubbish.

    3. Re:But is it secure? by Anonymous Coward · · Score: 1, Funny

      If the "byte array mapped to RAM" installed in Tamarin allows the code to store anywhere in the interpreter's space, that's a huge security hole.

      Yes, it is a security hole. It is also a huge win.

      The ability to perform pointer arithmetic and manipulate RAM without overhead is indispensable in many applications. I have personally had to suffer mitigation of GC overhead, bounds checking, extra copies, etc. on the JVM, CLR and the AVM. CLR gives you a fairly easy way out with "unmanaged" code. Where you lack this ability you must struggle to prevent unnecessary copies and allocations and still end up with a lower performing result.

      Obviously this is inappropriate for insecure web distribution, but there are *many* vertical applications that could leverage this. Think smartphones. You could eradicate nearly all "native" code if you could only do pointer arithmetic in ActionScript. Down at the bottom, where it really counts, buffers are filled and buses are driven, "managed" memory is unacceptable, period.

      Low level languages such as C will not be threatened by challengers that lack pointer arithmetic. Simple as that.

    4. Re:But is it secure? by ignavus · · Score: 1

      So is it C *without* pointers? Or is it C *with* pointers that can't point wherever a C pointer can?

      Pointers are the dark evil of C. Pointers and lack of buffer lengths. Oh, and the lack of garbage collection. And the lack of OO support (no I am *not* looking at you C++).

      But anyway, we might get Objective-C on browsers. About time. The first browser was written in Objective-C.

      Hm, cross-platform Cocoa?

      --
      I am anarch of all I survey.
    5. Re:But is it secure? by kestasjk · · Score: 1

      If the "byte array mapped to RAM" installed in Tamarin allows the code to store anywhere in the interpreter's space, that's a huge security hole. It can do anything the user process can do. If you're going to allow that, you may as well just load executable machine code directly, as with Active-X.

      You should email them and tell them about this! Surely they haven't though of such a thing!

      Sarcasm aside (sorry, I couldn't help myself), I suspect the VM needs to actually hand you a block of memory, and on accesses it validates that it is within the VM allocated range. Anything less would be silly, however such a thing would provide a huge win (I've tried to do image editing in pure managed code, and then found a massive performance win switching it over to P/Invoke native code).

      I'm all for web-apps but I really hope we don't start seeing image editing in browsers..

      --
      // MD_Update(&m,buf,j);
    6. Re:But is it secure? by Anonymous Coward · · Score: 0

      I suspect the VM needs to actually hand you a block of memory, and on accesses it validates that it is within the VM allocated range.

      In this context isn't "suspect" another way of saying "assume"? In which case "assume = arse out of U and me". Never assume anything ;-) They probably haven't thought of it.... scary!

    7. Re:But is it secure? by Threni · · Score: 1

      > Pointers are the dark evil of C. Pointers and lack of buffer lengths. Oh, and the lack of garbage collection. And the lack of OO
      > support (no I am *not* looking at you C++).

      They're fast though. Pointers, I mean. To memory you manage yourself - get rid of when you know you no longer need it.

      Of course, you need to know what you're doing. It's the manifest lack of programmers who know how to code using pointers which is the problem, not the language.

  14. The next breakthrough after Browser -C by 140Mandak262Jamuna · · Score: 2, Funny

    ... is definitely going to be browser-FORTRAN.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:The next breakthrough after Browser -C by trongey · · Score: 1

      I want my,
      I want my,
      I want my PL/1.

      --
      You never really know how close to the edge you can go until you fall off.
    2. Re:The next breakthrough after Browser -C by kvezach · · Score: 1

      Browser-INTERCAL.

  15. Sounds fantastic by dedazo · · Score: 2, Insightful

    And highly exploitable as well.

    --
    Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    1. Re:Sounds fantastic by UnknowingFool · · Score: 4, Funny

      I feel a great disturbance in the force as if a million admins suddenly screamed in terror . . .

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    2. Re:Sounds fantastic by dedazo · · Score: 5, Funny

      Those who don't remember ActiveX are doomed to reinvent it. Poorly.

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    3. Re:Sounds fantastic by DoofusOfDeath · · Score: 4, Funny

      Those who don't remember ActiveX are doomed to reinvent it. Poorly.

      A poorly re-invented ActiveX? I feel like I've just stared into the abyss, and seen Bill staring back at me.

    4. Re:Sounds fantastic by Achoi77 · · Score: 1

      Who's the more foolish: The fool, or the fool who follows him?

    5. Re:Sounds fantastic by Anonymous Coward · · Score: 0

      don't you mean poorly-er?

    6. Re:Sounds fantastic by danhuby · · Score: 1

      The two flaws with ActiveX in my opinion were:

      1) Platform dependency - it was Windows only.

      2) Security - ActiveX applications could do anything they liked.

      Although I find the idea of running C code in a browser completely unnecessary, in it's favour this solution does seem to solve the two issues above because it is platform independent and runs in a VM. Quite a lot like a Java applet.

      So I don't think it's a poorly reinvented ActiveX, but I don't see why it is needed at all.

      Maybe it's a potential way to run legacy applications via a browser, but you'd be better off rewriting it as a 'true' web application.

      Dan

  16. Am I the only one feeling... by Anonymous Coward · · Score: 0

    ...that this is our doom?

  17. Purpose? by roman_mir · · Score: 3, Insightful

    This is an interesting hack but it does not do anything for improving either computational theory or improving web application development. Combine C arrays that can be coded within a page like Javascript with a web-browser's security model and you get yourself what exactly? Is this going to improve the speed of development, the security of a thin client, the stability of a browser, the ease of memory usage, the consistency of interfaces or reusability of code? Certainly there will be more features available to a browser client but will there be enough abstraction between the machine and the code to avoid having major security/consistency problems?

    It is just not clear to me right now whethere there is a purpose to this beyond satisfaction of an interesting hack.

    1. Re:Purpose? by Anonymous Coward · · Score: 0

      Repurposed library code.

    2. Re:Purpose? by Anonymous Coward · · Score: 0

      This is an interesting hack but it does not do anything for improving either computational theory or improving web application development. Combine C arrays that can be coded within a page like Javascript with a web-browser's security model and you get yourself what exactly? Is this going to improve the speed of development, the security of a thin client, the stability of a browser, the ease of memory usage, the consistency of interfaces or reusability of code? Certainly there will be more features available to a browser client but will there be enough abstraction between the machine and the code to avoid having major security/consistency problems?

      It is just not clear to me right now whethere there is a purpose to this beyond satisfaction of an interesting hack.

      You miss the point. No sane or intelligent developer would write a NEW application in C just to run it in a web browser -- there are already plenty of better options available. This technology is useful because you can take an already-existing application written in C and use and/or deploy it over the web. It is a tool for code reuse, and in that way, it very much does improve web application development.

    3. Re:Purpose? by roman_mir · · Score: 1

      Not true, any code that is written in C so far, was not ever written to run within a context of a VM within a web browser. Since this is a new context none of the existing applications written in C would be suitable for such environments. On the other hand things like Perl to C translators can be used, however there is no reason to go that complex road to achieve something that can be done with Javascript and regular expressions anyway.

  18. Ah, the Memories... by Tickenest · · Score: 5, Insightful
    Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music.

    So Flash can simulating computing as it was back in 1998? Super....

    --
    This is the NFL, which stands for "Not For Long" if you keep making those bulls*** calls.
    1. Re:Ah, the Memories... by JoshJ · · Score: 2, Informative

      Zelda was 1986 on the Family Computer. You're 12 years off.

    2. Re:Ah, the Memories... by VGPowerlord · · Score: 1

      >>>Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music.

      >>So Flash can simulating computing as it was back in 1998? Super....

      >Zelda was 1986 on the Family Computer. You're 12 years off.

      Reading comprehension is everything. The bolded areas above contain what you missed.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    3. Re:Ah, the Memories... by AllIGotWasThisNick · · Score: 1

      You're 12 years off.

      The C-based emulator in question wasn't written for a few more years, I guarantee it.

    4. Re:Ah, the Memories... by Tickenest · · Score: 1

      Yeah, but I mean that NES emulation first got big around 1998.

      --
      This is the NFL, which stands for "Not For Long" if you keep making those bulls*** calls.
    5. Re:Ah, the Memories... by Anonymous Coward · · Score: 0

      I would think he was referring to the emulation of zelda, not zelda on its native platform.

    6. Re:Ah, the Memories... by caywen · · Score: 1

      You don't get it. It's running in a *browser* - don't you see how awesome that is? I don't either.

    7. Re:Ah, the Memories... by Anonymous Coward · · Score: 0

      You forgot to boldface emulator as well as pointing out that there have been many Zelda's, many of which post-date the 80's entirely.

      As you said, comprehension is everything.

      I do have to echo the original sentiment. I find constant amusement in the fact that Flash technology allows me to play games on my dual-core 4gig ram desktop computer at the same speed they run on my cell phone.

    8. Re:Ah, the Memories... by Jesus_666 · · Score: 1, Funny

      That's because you're not 2.0 enough. Everything gets better when run inside a browser. If you have Firefox, you can type chrome://browser/content/browser.xul into the URL^H^H^HAwesome bar. That will run Firefox inside Firefox, exponentially increasing the awesomeness. I tried it and I came when I reached the third layer. That's how awesome running stuff inside a browser is.

      I really hope Firefox 4 will have full DirectX 12 support so I can play all my games inside it as well. Also, the next CPU enhancement (like SSE or 3DNow!) will most probably be something that specifically speeds up browsers. Because running stuff in browsers is that awesome and everyone will do it in the furure, even BIOS vendors.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    9. Re:Ah, the Memories... by master_p · · Score: 1

      It can be called 'Flash-Back'....

    10. Re:Ah, the Memories... by caywen · · Score: 1

      Yeah! I'm still waiting to play Diablo 3 in my browser. It just wouldn't be as awesome without the back/forward and refresh buttons :-)

  19. Awesome by iXiXi · · Score: 2, Funny

    All that and a free dozen eggs every 10 secs. What will they think of next?

  20. This confirms it C is Death! by SmallFurryCreature · · Score: 3, Funny

    The more you run away from it, the closer you get to it. So now things are as inevitable as Death, Taxes and C.

    A frightful three-some indeed.

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

    1. Re:This confirms it C is Death! by Anonymous Coward · · Score: 0

      Therefore:
      Energy = Mass * (the speed of Death ^2)

  21. Very good by gweihir · · Score: 1

    So the language for ''real men'' will not die out! All those kids playing with their scripting or byte-code should watch out!

    Seriously, I like Perl and Python. But some things, expecially real-time stuff like audio and video are not for scripting.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Very good by X0563511 · · Score: 1

      Use scripting/interpreted stuff for some things, and for the time-critical use 'bindings'. We do that already. Python-OpenGL - python itself isn't rendering the tris... that would (indeed!) be quite silly.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    2. Re:Very good by tepples · · Score: 1

      Use scripting/interpreted stuff for some things, and for the time-critical use 'bindings'. We do that already. Python-OpenGL

      What do you use to decompress textures, read controllers, play sounds, or do any other signal processing or I/O that the Python standard library and OpenGL don't handle by themselves? You have to find or write a C extension, and then you have to port it to each platform that you plan to support.

  22. Adobe Systems != Open Source by mpapet · · Score: 5, Informative

    The last time I checked, Adobe Systems is about as hostile to open source as possible. They are the seldom acknowledged masters of the "first hit on the crack pipe is free" scheme.

    http://labs.adobe.com/technologies/eula/air.html

    Multiple helper libraries licensed under the MPL doesn't change the fact they are promoting another information silo.

    --
    http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
    1. Re:Adobe Systems != Open Source by Anonymous Coward · · Score: 0

      When you say:

      the "first hit on the crack pipe is free" scheme

      Are you referring to their acceptance of the existence of pirate versions of Photoshop, knowing that it enforces their market share and results, ultimately, in Photoshop being the standard/only corporate photo editing solution?

      If so, the "first hit" seems to last forever (or until you get a job for a corporate who pays for your copy of PS). In any case, who needs open source when the "free" (as in beer) version is better than the OSS equivalent?

      </troll>

      P.S It does suck having to run the old *NIX/WINE/PS stack I admit...

    2. Re:Adobe Systems != Open Source by obi · · Score: 2, Informative

      Well, Tamarin is completely open source (MPL/GPL/LGPL triple licensed - see http://www.mozilla.org/projects/tamarin/faq.html#license). The Flash specs are completely open now, see http://www.adobe.com/openscreenproject/. The Flex SDK has an open source compiler for your actionscript to swf bytecode needs. You can also check http://opensource.adobe.com/ for more projects under a variety of licenses like MIT, LGPL3, etc.

      So what exactly are you complaining about? Air and the flash plugin are closed yes, but the specs and compilers and vm have been opened up by them. And there's already a lot of open source projects making use of these.

      Not that I think Adobe are the greatest thing since sliced bread; but I don't think they're "about as hostile to open source as possible", especially if you compare them to other companies their size/field.

  23. Don't laugh. by Anonymous Coward · · Score: 0

    I heard that COBOL is next on the TODO list.

    Don't laugh too hard. All those COBOL guys are retiring now and there's still a shit load of stuff out on COBOL - including NEW software. COBOL guys aren't hurting, that's for sure.

    1. Re:Don't laugh. by Spinlock_1977 · · Score: 1

      Bullocks! Haven't seen a decent Cobol job offer in decades. Unless $35/hr means 'aren't hurting'.

      --
      - The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
    2. Re:Don't laugh. by Anonymous Coward · · Score: 0

      If $35 an hour to work in an office with minimal discomfort counts as "hurting" to you, then you haven't seen anything close to real pain.

    3. Re:Don't laugh. by Spinlock_1977 · · Score: 1

      I think the gist of this thread is the notion of comparing Cobol jobs to more modern .net and java jobs. We're not really comparing Cobol job to hunting for grubs in the desert.

      --
      - The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
    4. Re:Don't laugh. by Lodragandraoidh · · Score: 1

      Assuming a 40 hour work week for 52 weeks, that works out to $72,800 per year - with at least 2 weeks of paid vacation.

      You are upper middle class in most places in the USA - and your wife doesn't have to work. Congratulations. You salary is in the top 15% of the population.

      Gives new meaning to the word 'hurt', doesn't it?

      --

      Lodragan Draoidh
      The more you explain it, the more I don't understand it. - Mark Twain
  24. I can already C the future (sorry 4 pun) by caywen · · Score: 1

    I get it! So, now we have interpreted C, and it's (relatively) strongly typed! Wow, so because of that, we can deduce a lot of runtime information at compile time. Thus, potentially, the interpreter could optimize. And for the ultimate speed gain, they will find a way to turn that interpreted C into native machine language. And then it'll run really fast. Yeah.

  25. Perl is Interpreted C by Doc+Ruby · · Score: 4, Interesting

    There's very little if any C code that can't be written basically the same for Perl to interpret it basically the same way. The exception is direct memory access, but there are ways. And besides, I'd rather access memory through an API that really manages it, like making it hard to unexpectedly overflow buffers or grant access to unauthorized other users.

    I'd love a Perl interpreter embedded in my browser. I'd love to have a Perl API directly to the browser app and the browser documents' DOM. I'd love to have a "Perl commandline" that returns text like usual, or that works on remote data by URL, or that returns icons or other data displayable in the browser.

    Javascript is a pain in the ass. I'd rather have a Perl engine, and all the Perl modules and scripts, to run against my browser the way I usually run against my terminal window.

    --

    --
    make install -not war

    1. Re:Perl is Interpreted C by Anonymous Coward · · Score: 0

      Yeah, well a Python can eat perls...can your perl do that?

    2. Re:Perl is Interpreted C by joekrahn · · Score: 1

      Isn't Java closer to C than Perl? In my experience, most difficulties with Javascript is not the language syntax, but inconsistent object and environments by different browsers (with MSIE being the biggest problem.)

      I have always thought that we just need a standard pseudo-assembly bytecode which can be compiled from a variety of languages from existing compilers, and all be run from a standardized interpreter. I would think that even Perl could be implemented this way, along with a big run-time library.

    3. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      Yes, Perl's Parrot eats pythons.

      --

      --
      make install -not war

    4. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      Perl is closer to C than Java is to C. They're each pretty close, but Java is always object-oriented, closer to C++ (but without a lot of C++ complexity and flexibility). Also, Perl includes references to objects and values, while Java does not. Java is a lot more strongly typed than is either C or Perl.

      For the "standard pseudo-assembly bytecode" that is compiled from various languages, you're looking for Parrot, built to support Perl6, but also supporting other languages, that runs them as virtual machine bytecode.

      --

      --
      make install -not war

    5. Re:Perl is Interpreted C by jez9999 · · Score: 1

      I'd love a Perl interpreter embedded in my browser.

      Ever used emacs?

    6. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      Yes, but I haven't noticed an emacs with a Firefox display mode.

      --

      --
      make install -not war

    7. Re:Perl is Interpreted C by mpeg4codec · · Score: 1

      Hear hear! I still can't understand why Perl is downplayed as a language. It has a great set of builtin functions, an incredible community (see CPAN and Perl Monks), can be written in a style that looks and functions exactly like C, and above all, its performance is pretty good.

      As noted, it can be used as C on steroids: built-in automatically growing/shrinking arrays, hashes (dictionaries to some), and completely automatic garbage collection. The syntax, being eminently flexible, can be made to look damn similar to C's.

      Beyond that, it gives you much more expressive power. In my opinion, in some situations it can be much more meaningful to say something like return unless $t > 0 versus the equivalent if (!($t > 0)) { return; }. Subtle things like that allow code to flow much more freely, and that's barely even scratching the surface.

      Perl gives you room to grow well beyond C (without requiring it, of course). Functional programming techniques abound since Perl's array data structure works equally well as a Lisp-like list. It has builtins such as map and grep and a standard bundled module that provides reduce, so virtually any functional programming task can be implemented easily.

      With everything it's got going for it, sometimes I'm left scratching my head as to why it's not used more widely. A couple of bad programmers write line noise and suddenly the whole reputation of the language is at stake. A sad thing indeed.

    8. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      If someone wrote the Perl browser plugin I described, that could revolutionize Perl's perception into "savior language for everything". Which is exactly what happened with CGI programming, even though restarting (and therefore recompiling) a Perl script with each HTTP hit was exactly the worst use case for the language.

      --

      --
      make install -not war

    9. Re:Perl is Interpreted C by kestasjk · · Score: 1

      Because dealing with files, processing text and acting as a glue between different applications is exactly the job JavaScript has to do?

      For traversing the DOM and performing web related tasks and handling web related events JavaScript is at least adequate. (And pretty impressive considering it was created in large part by competing companies as a way of drowning each other out. Kudos to the ECMA guys for turning that mess around.)

      --
      // MD_Update(&m,buf,j);
    10. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      There's no reason Perl can't do all that. In fact, dealing with files, processing text and gluing apps together are Perl's strengths. Perhaps you meant to type Perl instead of Javascript in that sentence, but then I don't follow you.

      For traversing the DOM, Perl would be just as syntactically appropriate, with a Perl DOM API. There's nothing else in the functions and events of "web related" objects and actions that Perl isn't also suited to. It's a lot better suited to the tasks than just "adequate". Yes, ECMAScript had a lot of work to reconcile competing, incompatible scripts, but that wasted a lot of effort that didn't then go into making a language that's just the best.

      So a Perl plugin with a DOM API would be even better. And use the large library of Perl, as well as the large community of Perl programmers. Perl still wins.

      --

      --
      make install -not war

    11. Re:Perl is Interpreted C by kestasjk · · Score: 1

      Whatever you say.. Though I could say the same thing for any language I like. "Why can't my language be the web scripting language?"

      And in the first sentence I was saying Perl is useful for those things, but those things have nothing to do with what JavaScript is used for. Perl has nothing that would give it an advantage over JavaScript, or any other language, for web scripting, other than that you like it.

      --
      // MD_Update(&m,buf,j);
    12. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      One advantage is that lots of people, not just me, have liked Perl enough to have written a large, easily accessible library of code for doing all kinds of things.

      Another advantage is that Perl is a much higher performance language than Javascript.

      And then there's the flexibility of Perl's syntax and native complexity of data structures.

      Perl is a much better language than Javascript in practically every way. The only limit is that Perl doesn't run in browsers against the browser and DOM APIs. That's why I like Perl, and why it would be a good browser plugin like I described.

      See how someone actually forms an argument when they believe something? We back it up with facts and logic. Passive aggression like "whatever you say" doesn't cut it, nor mere assertions denying my argument, nor do empty promises to say the same thing for any language you like, when you can't even say it substantially about Javascript, which you're defending. So despite my giving you the respect of a reasonable argument, you've given me only a snotty attitude. So I accept your giving up, but it wasn't any fun to force it out of you.

      --

      --
      make install -not war

    13. Re:Perl is Interpreted C by mesterha · · Score: 1

      I have to agree with kestasjk. Your argument amounts to why you like Perl not what makes Perl well suited to a browser scripting language. I'm sure we would all like to have our favorite languages used in popular applications and standards.

      --

      Chris Mesterharm
    14. Re:Perl is Interpreted C by Jesus_666 · · Score: 1

      And then there's the flexibility of Perl's syntax and native complexity of data structures.

      Ah, you're talking about obfuscation! Okay, Perl does win that one, hands-down.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    15. Re:Perl is Interpreted C by Doc+Ruby · · Score: 0

      Except that the reasons I like Perl are the same as the reasons it's a good browser scripting language. How would those two arguments be different, anyway?

      The main point is that Perl is better than Javascript. Which would also sound a lot like "why I like Perl".

      --

      --
      make install -not war

    16. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      The "Obfuscated Code" contest originated with C. Any language capable of succinct syntax therefore also has the power to be easily obfuscated. Perl is no different from C. But that's not necessary: the language's flexibility allows highly self documenting code. Show me how Javascript regexes can include literal comments, and then tell me that Perl can't be clearer than Javascript.

      I prefer to enforce code's effective communication with humans through coding guidelines. And take the language's power to communicate with the machines unconstrained.

      --

      --
      make install -not war

    17. Re:Perl is Interpreted C by kestasjk · · Score: 1

      One advantage is that lots of people, not just me, have liked Perl enough to have written a large, easily accessible library of code for doing all kinds of things.

      Like Python?

      Another advantage is that Perl is a much higher performance language than Javascript.

      Like Python?

      And then there's the flexibility of Perl's syntax and native complexity of data structures.

      Like Python?

      Perl is a much better language than Javascript in practically every way.

      Like Python?

      (Replace Python with any widely used language)

      See how someone actually forms an argument when they believe something? We back it up with facts and logic. Passive aggression like "whatever you say" doesn't cut it, nor mere assertions denying my argument, nor do empty promises to say the same thing for any language you like, when you can't even say it substantially about Javascript, which you're defending. So despite my giving you the respect of a reasonable argument, you've given me only a snotty attitude. So I accept your giving up, but it wasn't any fun to force it out of you.

      Way to put words in my mouth. "I accept you giving in to my superior logic and reasonable arguments, when you did no such thing."

      Get over yourself moron; not everyone likes Perl as much as you do.

      --
      // MD_Update(&m,buf,j);
    18. Re:Perl is Interpreted C by kestasjk · · Score: 1

      Except that the reasons I like Perl are the same as the reasons it's a good browser scripting language. How would those two arguments be different, anyway?

      Because we're not all silly enough to think that one language is the best choice for all problems. A language designed to work with markup and browser events has pretty different requirements to a language designed to work with files and text processing.

      (P.S. If you decide to respond you need to do more than call my argument "snotty" and accept my "giving up")

      --
      // MD_Update(&m,buf,j);
    19. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      Yes, like Python. There is indeed a case to be made for a Python browser plugin, much like the case for Perl. If you actually made one - I never said there isn't.

      You've not made any logical point in this whole discussion. All you're doing is denying that I've made the points about Perl that I've actually made. You're not arguing for anything, and your arguments against Perl are specious, while ignoring the valid points I'm making.

      And now you're talking like an asshole. WHen in fact the "moron" in this discussion is surely the one who can't argue worth a damn. That would be you, in case you can't do the math on that one, either.

      Go to hell, jerk.

      --

      --
      make install -not war

    20. Re:Perl is Interpreted C by Doc+Ruby · · Score: 1

      The language you know is better than the one you don't if they're otherwise equal. If the one you know is more than adequate, it's better than the one you don't know even if the other one could be better for someone else.

      Now you're calling me silly. When you talk like that, you're snotty. But of course I've done more than just point out that you're snotty. I've pointed out that your argument is wrong. And you've conceded, so I've accepted.

      But even that's not good enough for you. So you can now have your snotty argument with yourself, or someone else who cares.

      Go and do whatever morons do. Goodbye.

      --

      --
      make install -not war

    21. Re:Perl is Interpreted C by kestasjk · · Score: 1

      Okay, so if your argument is so bulletproof and you are so great at it go convince Mozilla to make a Perl extension.

      Go Doc Ruby! Use your superior arguing skills to convince the non-believers!

      I look forward to seeing the Perl mod in the next version of Mozilla. (Or maybe this whole thread was just the wet dream of a Perl-fanatic who can't learn good JavaScript? We'll let the results of your superior logic speak for themselves)

      --
      // MD_Update(&m,buf,j);
    22. Re:Perl is Interpreted C by kestasjk · · Score: 1

      But of course I've done more than just point out that you're snotty. I've pointed out that your argument is wrong. And you've conceded, so I've accepted.

      While you're fantasizing about your favorite language replacing JavaScript you might as well fantasize about me conceding to your great debating skills.

      --
      // MD_Update(&m,buf,j);
    23. Re:Perl is Interpreted C by kestasjk · · Score: 1

      (Reality can't be fun for a Perl fanatic)

      --
      // MD_Update(&m,buf,j);
  26. Guitar Hero and Lumines by tepples · · Score: 4, Informative

    Nope. SFX is generally event driven (hit a key, hear the sword swing) where music is not (enter an area and music plays continuously in the background).

    SFX requires timing, latency, and speed to be accurate. Music requires bandwidth and a minimum level of continuous CPU cycles.

    Both have different needs so you can have one without the other (when you are talking emulation).

    In Parappa the Rapper, Beatmania, Guitar Freaks, Drummania, Keyboard Mania, Frequency, Amplitude, Taiko Drum Master, Donkey Konga, Guitar Hero, Rock Band, and even scenes in the Mario Party and WarioWare series, the player triggers sound effects at specific times, and these sound effects represent music that the player is performing. If the background music becomes desynchronized from the sound effects that represent music, the emulated environment becomes unusable. Even games that aren't directly about performing music, such as Rez, Lumines, and some scenes in Super Mario RPG, indicate the timing of various game world events using the music.

    1. Re:Guitar Hero and Lumines by VGPowerlord · · Score: 1

      Nope. SFX is generally event driven (hit a key, hear the sword swing) where music is not (enter an area and music plays continuously in the background).

      SFX requires timing, latency, and speed to be accurate. Music requires bandwidth and a minimum level of continuous CPU cycles.

      Both have different needs so you can have one without the other (when you are talking emulation).

      In Parappa the Rapper, Beatmania, Guitar Freaks, Drummania, Keyboard Mania, Frequency, Amplitude, Taiko Drum Master, Donkey Konga, Guitar Hero, Rock Band, and even scenes in the Mario Party and WarioWare series, the player triggers sound effects at specific times, and these sound effects represent music that the player is performing. If the background music becomes desynchronized from the sound effects that represent music, the emulated environment becomes unusable. Even games that aren't directly about performing music, such as Rez, Lumines, and some scenes in Super Mario RPG, indicate the timing of various game world events using the music.

      These are the exception, not the rule.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    2. Re:Guitar Hero and Lumines by Anonymous Coward · · Score: 0
    3. Re:Guitar Hero and Lumines by tepples · · Score: 0

      [Rhythm games] are the exception, not the rule.

      Then I guess the exceptions are selling exceptionally well, wouldn't you think?

    4. Re:Guitar Hero and Lumines by VGPowerlord · · Score: 1

      Rez, Lumines, and Super Mario RPG are rhythm games?

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    5. Re:Guitar Hero and Lumines by Anonymous Coward · · Score: 0

      These games can work as they do because of direct control over the sound hardware - generally, you write PCM data to a buffer and it plays with a guaranteed level of latency, thus while the internal implementation is typically divided between sound effects and streamed music/VO, the output method is uniform for both.

      Flash 9 can only get buffered audio through a hack(start playing a looping sound constructed at runtime through Bytearray manipulation, and then rewrite parts of the array), but version 10 will fully support this.

      However, latency is and will continue to be high because of the audio APIs currently used - a major change is planned. The Adobe dev blogs have more on this.

    6. Re:Guitar Hero and Lumines by kjots · · Score: 1

      Then I guess the exceptions are selling exceptionally well, wouldn't you think?

      What the hell does that have to do with anything?

      Hold on, let me translate your statement into real words:

      I'm so in love with my own opinion that, even though my argument has been successfully countered, I'll through a complete non sequitur into the mix whilst misrepresenting the previous poster's sentiment.

      Let me clear things up for you, just in case you're too dense to figure it out yourself: In all the cases you cited above, the music is being used as a sound effect. That does not make all music sound effects, no matter how many units are sold.

      Do you get it now, dickhead?

    7. Re:Guitar Hero and Lumines by tepples · · Score: 0

      Rez, Lumines, and Super Mario RPG are rhythm games?

      Those are not music performance games. But part of my point was that these three examples do have rhythm elements (Rez: whole game; Lumines: whole game; SMRPG: Yo'ster Isle footrace), which break a strict interpretation of 2nd Post!'s proposed dichotomy between music and sound effects.

  27. bizarre by speedtux · · Score: 3, Insightful

    Trying to retrofit C into Tamarin seems bizarre. Why not use an on-the-fly sandboxing native C compiler? Tiny C (tcc) would seem like a good start.

    http://bellard.org/tcc/

    1. Re:bizarre by Anonymous Coward · · Score: 0

      I won't be running random bytecode over the web and I especially wont be running C directly in my browser any time soon. However if I were a potential Adobe Air or Mozilla extensions developer with an existing C codebase, I think I'd be excited by the (admittedly) limited potential on offer here.

  28. Startup latency by IamTheRealMike · · Score: 5, Interesting

    Being able to run Python or Quake inside a Flash VM sounds useful at first blush, but it seems you'd lose most of what makes webapps nice for both developers and users. In particular, C based apps are not designed to be streamed, whereas Flash or AJAX apps usually are (to some extent). Nobody wants to browse to a "web app" and then spend 5 minutes twiddling their thumbs whilst 20 megabyte of Python runtime or Quake is pulled down over the wire. Web apps just have a different DNA to desktop apps.

    I can see this being used to accelerate computation-heavy subelements of a regular Flash app though. I wonder how much of this is being driven by a desire to run a Photoshop subset inside Flash?

    1. Re:Startup latency by Anonymous Coward · · Score: 0

      Web apps just have a different DNA to desktop apps.

      I nominate you for the management-speak of the day award.

    2. Re:Startup latency by supermansuper · · Score: 1

      Photoshop subset inside Flash? Sounds like a great idea!!! Something like this: www.photoshopexpress.com.

    3. Re:Startup latency by Anonymous Coward · · Score: 0

      spluh! web apps have even more runtime, you just don't notice it because it's already loaded (the browser..)

    4. Re:Startup latency by spinkham · · Score: 1

      In order to make C anything approaching safe, you're going to end up with something that has the speed of Java or less, with similar memory requirements. And we all know how well Java applets went over.
      The only upside is the ease of compiling existing C code, vs rewriting code in java. And if it already exists in C form and I need it, I'd rather just run it locally thanks.

      --
      Blessed are the pessimists, for they have made backups.
  29. I want an internet plugboard ... by BigBunny · · Score: 1

    ... with a slot for each url.

    --
    old geek
  30. LOL by Pharago · · Score: 1

    oh my jesus christ monkey balls

  31. Flash? by andy19 · · Score: 1

    I thought the "new" web was trying to get away from Flash?

    1. Re:Flash? by Anonymous Coward · · Score: 0

      This thing is from Adobe, who wants to assimilate the Web.

    2. Re:Flash? by Briareos · · Score: 1

      I thought the "new" web was trying to get away from Flash?

      1. Embrace
      2. Extend
      3. Extinguish

      As far as Flash and this article is concerned, I'd say we're at step 2 currently. So step 3 can't be that far off... :P

      np: T.Raumschmiere - Leichtes Kratzen (Anti)

      --

      "I'm not anti-anything, I'm anti-everything, it fits better." - Sole

    3. Re:Flash? by Tatsh · · Score: 1

      Me too. I cannot wait till Flash is replaced with SVG+Javascript or anything else. It sucks

    4. Re:Flash? by Jesus_666 · · Score: 1

      While Tamarin is the ActionScript interpreter for Flash, it also will be the JavaScript interpreter for a future version for Firefox. So we can also expect C in JavaScript.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
  32. Great, just another layer by jmerlin · · Score: 0

    I predict 20 years from now that there will be 10+ layers of virtualization to "safely" run "web applications" and plenty of viruses running around causing trouble.

  33. That's not browser scripting! by Anonymous Coward · · Score: 0

    Uh... that's not browser scripting, that's plugin scripting.
    You can do anything with the right plugin...

  34. Yes, but... by vimm · · Score: 3, Funny

    ... can it run Linux?

  35. Wow. by zero1101 · · Score: 1

    The potential security implications of this kind of make me queasy.

  36. Crazy thoughts..... by jmorris42 · · Score: 3, Interesting

    > You realise that all the OS layers, networking layers, web browsers,
    > scripting languages are primarily to try to get away from C?

    So? You are missing the bigger point. All of those layers and scripting languages you speak of are written in C. So C working in Flash means all of that other stuff can be brought over. Perl + Flash? Python + Flash? Ruby? The mind boggles at the possibilities.

    Of course since nobody will want to stuff all of Perl + half of CPAN down the pipe every time an applet loads we will end up with predownloaded versions cached for use. Let the package war begin, will flash binary packages be maintained with .deb or .rpm... I can see Windows users fighting Package Kit or Synaptic to manage the cruft needed so that "web apps" can work. We could end up with an entire GNU/Flash[1] distribution lurking on every Windows PC.

    [1] I object to the GNU/Linux misnaming abomination but this time it really will be a "GNU" distribution since Linux won't be involved. At least until we get a formal 'distribution' being shipped by Adobe.

    --
    Democrat delenda est
    1. Re:Crazy thoughts..... by rrohbeck · · Score: 1

      Of course since nobody will want to stuff all of Perl + half of CPAN down the pipe every time an applet loads

      Why not? It'll be cached in the browser and startup can't take much longer than revving up a JVM or downloading all the JS and Flash scripts that today's sites need.

      If there's a fine-enough-grained package management we can have lots of goodness out of this.

  37. Can you say Active-X by Anonymous Coward · · Score: 0

    What a boon to malware writers everywhere, totally portable RAM access to your machine.

  38. Re:am I the only one bored with the software world by Anonymous Coward · · Score: 0

    Everything's being constantly reinvented but no actual progress is being made. Oh look, the 100th toolkit to do exactly the same thing! Oh look, a new way of layering something old on something old on something old to give something new! Oh look, another silver bullet framework!

    Can anyone here remember the web of 10 years ago, for example? Content = text for reading + graphics for illustration. No bullcrap, just Google/Wikipedia style web sites to give me a simple navbar + content.

    Hear! Hear! The best websites have nothing but text. Your comments are excellent, never mind the slashdot moderation/censorship system - I know how to get around it, found your comment, read it and appreciated it greatly. You are not the only one who thinks this way.

  39. A mighty hack, but of dubious use. by Peganthyrus · · Score: 4, Informative

    Hooray! Now C programmers can join the fun of writing sluggish applications that eat up huge amounts of CPU even when they're doing nothing!

    Deceptive headline, too, as this is just about compiling C to the bytecode that the Flash player interprets. Or even worse, now that I RTFA: "The LLVM instructions are converted into opcodes for a custom Virtual Machine that runs in ActionScript, a variant of ECMAScript and sibling of JavaScript." So your C is compiled to bytecode, that is interpreted by an interpreter that is, itself, a stream of the Flash player's bytecode.

    Moore's Law notwithstanding, this is a pretty insane use of processor cycles, guaranteed to make your program run a couple orders of magnitude slower than it would if you actually compiled it, or rewrote it in Actionscript!

    --
    egypt urnash minimal art.
    1. Re:A mighty hack, but of dubious use. by Bill+Kendrick · · Score: 1

      "this is just about compiling C to the bytecode that the Flash player interprets"

      Well hey there. Port SDL to it, and I can finally make a lot of people happy by saying "YES, you CAN run Tux Paint in a web browser." :)

  40. Re:am I the only one bored with the software world by LilGuy · · Score: 1

    I also remember waiting 5 minutes for a picture to download...

    I don't mind having nice looking sites because it takes just as long for one of them to load as it does for a plain text site anymore.

    However, people have shifted more toward flashiness than content which I don't particularly like.

    --

    You're nothing; like me.
  41. What's new? by DerPflanz · · Score: 1

    I wrote my first CGI programs in C, using the cgi-c library. In fact, it is still online for download!

    I know, this is not the same, but that's what I thought when I read the headline.

    --
    -- The Internet is a too slow way of doing things, you'd never do without it.
  42. but ... by Anonymous Coward · · Score: 0

    does it run Linux ?

  43. Easier way... by Anonymous Coward · · Score: 5, Interesting

    chrome://browser/content/browser.xul

    Firefox inside Firefox inside Firefox...

    1. Re:Easier way... by springbox · · Score: 1

      wow I just tried that. "Mozilla Firefox - Mozilla Firefox." Made it temporarily look like IE7's backwards user interface.

    2. Re:Easier way... by rrohbeck · · Score: 1

      Cool! Finally I can build a tree of tabs, not just a linear list. Just what I needed to get lost completely.
      Now I want a VM running in a tab, or at least a separate process with its own window.
      And a Gecko ActiveX plugin so we can show IE users how to browse properly.

    3. Re:Easier way... by forkazoo · · Score: 1

      chrome://browser/content/browser.xul

      Firefox inside Firefox inside Firefox...

      Egad man, what evil genius dreampt up this beast? Seriously, this is awesome -- a whole new level of hierarchy for my zillion tab wikipedia benders.

    4. Re:Easier way... by Blastercorps · · Score: 1

      ....that's perverse....I love it.

  44. VB Next? by Nom+du+Keyboard · · Score: 1

    Let me know when they get full Visual Basic up and running. Then I'm interested.

    And I don't mean that C in VB Sheep's Clothing .NET version.

    --
    "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
  45. Re:am I the only one bored with the software world by thermian · · Score: 1

    Progress has slowed a little, but only because of the patents thing.

    Its just so hard at the moment to push new technology without people popping out of the woodwork and asking for their cut, even though they've done shit all except hoard bits of paper.

    Also, some of what is touted as new technology is really just something built to avoid some other buggers IP/patent trap.

    I'm sure it'll blow over. If it doesn't then dust will blow over the bleached carcass of the present IT world as the new guys (read India and China) take over the market.

    Aside from that depressing thought, progress is still being made, it's just hard to spot some days.

    --
    A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
  46. Other compilers... by mwkohout · · Score: 1

    Back in the old days(and still now) is that most compilers compiled to a intermediate language-often C.
    So what this really means is that (sometime soon)we'll be able to write in any language that can be compiled down to C...so Lisp, C++, Objective-C, welcome to the browser!

  47. Consistency... by GNUPublicLicense · · Score: 1

    Of course, tamarin (the adobe mozilla pet project that will be used to take over mozilla and screw the web) is written using C, isn't it? Or, is this a C++ bloat doomed to trash mozilla spidermonkey, the C coded webscript interpreter? Really I wonder, really...

  48. Re:am I the only one bored with the software world by swanriversean · · Score: 1

    don't forget, whatever you decide to do next, IBM did it on a mainframe 40 years ago, and it wasn't cool, even then

    --
    Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seus
  49. I wonder if it supports C completely by RWerp · · Score: 3, Funny

    For example, does it support buffer overruns? Double free's?

    --
    "Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
    1. Re:I wonder if it supports C completely by jesser · · Score: 1

      Yes, they still result in undefined behavior, per spec.

      --
      The shareholder is always right.
    2. Re:I wonder if it supports C completely by RWerp · · Score: 1

      I meant "support" as in "are they as easy to get as in C".

      --
      "Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
  50. ivm by Anonymous Coward · · Score: 0

    I though this was attempted way back with the http://sourceforge.net/projects/ivm/

    Looks like that project needs to be necroed

  51. Please clarify. by SilentBob0727 · · Score: 1

    I'm confused. Is it VM-executed-compiled C or C-like code interpreted on the fly?

    If it's compiled C, what platform is the VM emulating? Operating system matters!

    If it's interpreted... I just want to know: In what world is interpreted C a good thing?

    --
    Life would be easier if I had the source code.
  52. COBOL.NET... Language of the Future! by Flwyd · · Score: 1

    My programming languages class was treated to a talk by a guy who worked some on .Net from a theoretical standpoint. He gave a demonstration of a form-manipulation script running in IE. "What language is this written in? COBOL dot net, the language of the future!"

    I don't know what one needs to do to make it work, but scripting the browser (IE, anyway) is presumably already possible.

    --
    Ceci n'est pas une signature.
    1. Re:COBOL.NET... Language of the Future! by Shados · · Score: 1

      .NET forms can be embedded as dll/activex in internet explorer if explicitely given appropriate permissions. Its kindda cute as a deployement platform for internal applications I suppose.

      Personally, I prefer using ClickOnce or now Windows Presentation Foundation for that... easier, safer, more versatile, and better supported :)

  53. Dynamite is an old fire! by Anonymous Coward · · Score: 0

    It reminds me to tntnet, C++ webserver by Tommi MÃkitalo.
    See http://www.tntnet.org/

  54. another reason for web apps by Anonymous Coward · · Score: 0

    In your web browser, you can click on a link and read something, listen to something, watch something, play something.. that someone published on the web, with a few clicks of their mouse. And neither your nor they had to install or update anything. Most of the time, neither you nor they really need to worry about any breach in your or their security. The server only lets you see what it intends. Your browser only lets the server see what it intends; whatever the server serves up runs in a sandboxed environment within your browser. The more a browser can do, while maintaining and improving all that, the less people will want to bother with installing and updating software, and the less programmers will want to bother with targeting anything but the web.

    Computers are tools. They exist to be used. It's desirable to maximize what they can do and minimize the amount of effort involved in using them to do it. I agree, the Net is a horrible messy hodgepodge. We should replace the browser. We should replace HTML and CSS and JavaScript, etc, with something much, much better. But the reality is, reaching toward perfection is an evolutionary process, and having various competing browsers and such has been a very good thing - because of that healthy competition, the typical browser of today is far better than the ones we had 5 or 10 years back.

  55. CGI? by mckniffen · · Score: 1

    well I've always written my CGI executables in C so "web scripting" in C isn't anything new

    I don't know if its just me but rippng off the C syntax for an interpereted language is ridiculous. Please leave this to perl and flash.

    --
    Communism, its a party!
  56. 8088 emu by edgar_zavala · · Score: 1

    I was working in a 8088 emulator (aka XT emulator) in JavaScript... Long Live to x86 assembler!!! will be nice to run CP/M over javascript and a web browser.... but i think C code is just to much

  57. I put C on web pages at my last start-up by istartedi · · Score: 2, Interesting

    At the now defunct start-up I last worked at, we had the usual LAMP stack driving our product. For amusement (and because I think there is an awful lot of bloat in LAMP), I did a simple front-end to our product based on an approximately 1000-line web server I wrote, and web pages with C embedded in comments. The makefile ran the web pages through a munger that transformed them into C, then built them and linked them into the server. If you didn't want the tiny web server, it could have just as easily built them as an apache module. The downside was that web developers using such a system would have had to "modify, compile, reload in browser" as opposed to their usual "modify, reload in browser" cycle. IMHO, this alone would have killed it since web devs like fast turnaround on changes. Nevermind that the web devs would have had to learn C, and that it wouldn't have been sandboxed or been able to run code client-side. I still like the idea though, and I'm glad to see others not only think in a similar way; but do so using a platform that would resolve some of the aforementioned issues.

    My toy front-end was never put into production of course; but when I wanted to debug my code without pestering the web devs, and I needed something more than text, it was quite useful.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    1. Re:I put C on web pages at my last start-up by strcpy(NULL,... · · Score: 1

      I had a similar experience, in one of the institutions I worked I was tasked with writing an internal application although I wasn't hired as a developer. What I did was to write a pre-processor that let me mingle C code and HTML data together. Then I separated them with the preprocessor and linked them with the tiny webserver and the Internet Explorer widget (the client was very picky about how the application looked).

      I left the "Hey that button should be pink" bastards with the source code and docs for it all but I don't think anyone with a little sense in them would get anywhere near it. The whole thing was one big binary which ran as two threads, one for the webserver and one for the Internet Explorer window.

      Still I wish there was some mature platform which lets me do that. An HTML window controlled by C source is very nice. You don't have to deal with any fancy-schmancy GUI toolkit and you have all the power you will ever need.

      --
      echo 'cat sig | sh' > sig
  58. Standards? by hotfireball · · Score: 1

    But concerning standards on different browsers to avoid various problems, quirks and hacks, would be easier to adopt Brainfuck... :-)

  59. Re:am I the only one bored with the software world by beakerMeep · · Score: 1

    Content = text for reading + graphics for illustration.

    Hmm illustrated porn. I wonder if it had helpful arrows and thought bubbles.

    --
    meep
  60. Hey you bums!! by Anonymous Coward · · Score: 0

    You guys are confused by the way he said it, but he is right...

    A well designed web app form first does a client side javascript form validation on the data because this is instant feedback to the user.

    If this passes, you do a hard server side error check to make sure there in nothing sneaky being submitted.

    AJAX lets you skip that step. That's all he was trying to say.

  61. Next Step by Anonymous Coward · · Score: 0

    AssemblyScript

    This thing sounds like stepping backward for me. Python sounds good but not C. Dynamic Typing language is more suited for browser than the procedural one or static type one. If we were going to change the way web scripting works, it should be redesigning javascript by removing all weird stuff.

    Douglas Crockford gave a good overview on what's good and what bad in javascript
    http://video.yahoo.com/watch/630959/2974197

  62. Cool, with C you can run Lua by ockegheim · · Score: 1

    OK, I admit I learned Lua programming Warcraft addons, but I've found Lua to be a really friendly language for the hobby-programmer that I am, and now I'm using it for other projects. If a brower could run Lua I'd be tempted to take my web pages beyond HTML and CSS.

    --
    I’m old enough to remember 16K of memory being described as “whopping”
  63. Re:am I the only one bored with the software world by kestasjk · · Score: 2, Insightful

    Everything's being constantly reinvented but no actual progress is being made. Oh look, the 100th toolkit to do exactly the same thing! Oh look, a new way of layering something old on something old on something old to give something new! Oh look, another silver bullet framework!

    Can anyone here remember the web of 10 years ago, for example? Content = text for reading + graphics for illustration. No bullcrap, just Google/Wikipedia style web sites to give me a simple navbar + content.

    (Clicks reply to this, has text-box open up, clicks quote parent, has parent's comment show up, types comment)

    Yeah we all really desperately want to go to the web of 10 years ago.. Are you really saying the web is stagnating?
    It's the most quickly developing platform out there, and now more than ever. And thanks to open source it's more open than ever and browser wars are finally about being true to standards and not about breaking them.

    (Clicks preview, has comment show up, clicks submit, has comment displayed, continues reading from the comment directly beneath)

    --
    // MD_Update(&m,buf,j);
  64. Re:am I the only one bored with the software world by kjots · · Score: 1

    The problem is that software industry (FOSS or otherwise) is full of lightweights with no real understanding of computers or programming. The proof of this statement is in the pudding (i.e. the general low quality of software worldwide).

    Because computers are deterministic, one could in fact write software that is 100% reliable and bug free. It would just take a monstrous amount of time, and adding more people to the project will not make it go any faster (see Brook's Law).

    The market currently demands software at a rate many orders of magnitude more then it can be delivered. So the market compromises, as the market does, and tolerates substandard software. This practically guarantees that software will get progressively worse as time goes on.

    Franky, I think programmers should be educated much like doctors: After all, if just anyone could pick up a scalpel and call themselves a surgeon, people would be dropping dead left, right and center. The same strictures should apply to the software development industry. The market can crash and burn for all I care.

    By the way, just in case you're wondering, the Slashdot community is no exception.

  65. If It Runs Quake .. by Anonymous Coward · · Score: 0

    If it runs Quake, then I'm all for it. How can that be a bad thing?

    Does this mean that I can finally run Quake on my Cray?

  66. Whatever happened to... by T3Tech · · Score: 1

    thin clients or thick clients for that matter.

    --
    Of course I didn't RTFA... why would I do that? You really are new here aren't you? Don't let my UID fool you.
  67. secure Flash sandboxes ? by mAriuZ · · Score: 1

    "Petersen showed us the C-compiled versions of Lua, Ruby, Perl, and Python all running on the web in secure Flash sandboxes."

    that is an lie with secure Flash sandboxes

    http://blogs.adobe.com/psirt/2008/05/potential_flash_player_issue.html

    is like saying secure ActiveX...

    --
    developer http://flamerobin.org
  68. Re:am I the only one bored with the software world by Zebedeu · · Score: 1

    Do you also want us to get off your lawn?

  69. A possible mistranslation by tepples · · Score: 0
    I wrote:

    Then I guess the exceptions are selling exceptionally well, wouldn't you think?

    You mistranslated:

    I'm so in love with my own opinion that, even though my argument has been successfully countered, I'll through a complete non sequitur into the mix whilst misrepresenting the previous poster's sentiment.

    I'll suggest an alternate translation for you to consider: "If you design and market a video gaming platform without capabilities that allow the use of music as sound effects, you lose sales of games in a few lucrative genres to platforms that do."

    Do you get it now, dickhead?

    Why do you use such harsh language?

  70. And C++ as well by master_p · · Score: 1

    And let's not forget C++!!!!

    And boost!!!!

    Now that would be cool!!! a massive download just to run a few lines of C++ code...

  71. Re:am I the only one bored with the software world by dgcaste · · Score: 1

    It's not like we rely on RSS and server databases. cough slashdot cough.

  72. RTFA: Perl, Ruby, LUA, Python are up and running by egghat · · Score: 1

    "Petersen showed us the C-compiled versions of Lua, Ruby, Perl, and Python all running on the web in secure Flash sandboxes."

    Well there you have it ...

    --
    -- "As a human being I claim the right to be widely inconsistent", John Peel
  73. That's devolutionary by weebuzo · · Score: 1

    Writing a C binding to work in a Flash virtual machine is like writing an abacus emulator on Fortran to improve Fortran mathematical capabilities.

    The history has already evolved quite backwards.