Wayland and Weston 0.99.0 snapshots released
| From: | Kristian Høgsberg <hoegsberg-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org> | |
| To: | wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW-AT-public.gmane.org | |
| Subject: | Wayland and Weston 0.99.0 snapshots released | |
| Date: | Mon, 15 Oct 2012 23:00:27 -0400 | |
| Message-ID: | <20121016030027.GA13419@minato.local> | |
| Archive‑link: | Article |
Hello, After a couple of weeks of pretty intense activity, I've merged the ~krh/next branches back into wayland and weston master and released a 0.99.0 snapshot of both repos. At this point I've pulled all patches from the list and I feel that the big changes have settled in pretty well. We now have responsible error handling, we have a well-defined atomic update mechanism and event dispatching is thread safe. I've been very happy to see the effort and the amount of patches on the list recently, and without that we couldn't have wrapped up the protocol and client API changes in time. As I wrote before, we ended up with a little more API breakage than I had hoped for, and releasing 1.0 right after landing that feels a little reckless. So what I'd like to do is to spend a week now just porting clients and toolkits, fixing bugs and improving the documentation. In other words, we should see Wayland 1.0 on October 22nd. The 0.99.0 release tarballs are available here: http://wayland.freedesktop.org/releases/ And just for good measure, the SHA1 sums are: 0b2f6353831234f7f3689a388d390060b79f047b wayland-0.99.0.tar.xz f99b8c2d80fb255ac2245dccb8607bcc1342657e weston-0.99.0.tar.xz I have a wayland-0.99 branch here in my mesa repo: http://cgit.freedesktop.org/~krh/mesa/log/?h=wayland-0.99 that works with the recent API changes and expect to push that upstream tomorrow to master and hope to ship it in mesa 9.0.1. thanks, Kristian
Posted Oct 16, 2012 20:02 UTC (Tue)
by drag (guest, #31333)
[Link] (1 responses)
That means that people can actually start using it and targetting it and not expect any breakage, barring serious bugs?
If so then this is great news. :)
Posted Oct 16, 2012 20:08 UTC (Tue)
by adamgundy (subscriber, #5418)
[Link]
Posted Oct 16, 2012 20:23 UTC (Tue)
by nickbp (guest, #63605)
[Link] (28 responses)
Posted Oct 16, 2012 20:55 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 16, 2012 22:45 UTC (Tue)
by drag (guest, #31333)
[Link] (26 responses)
Posted Oct 17, 2012 9:45 UTC (Wed)
by ms (subscriber, #41272)
[Link] (24 responses)
I wonder therefore how much further we're going to go down the whole "let's support JS everywhere" route before we finally realise what an awful mistake the whole thing's been and how we really need to slowly migrate away to better designed technologies. Yes, HTML and CSS are fine for simple web pages. But if you want to go down the whole one-page-app route and actually treat the browser as a real programming environment, they're absolutely not fit for purpose.
Once that's been solved, I wonder if anyone will think JS should live on, eg in Gnome Shell support. Are there actually technical reasons to prefer JS over, say, lua, or even LISP (see StumpWM for example).
Posted Oct 17, 2012 10:40 UTC (Wed)
by Jonno (subscriber, #49613)
[Link] (1 responses)
If I sat down today to build a technology for doing cross platform app development I would likely come up with some XML-ish declarative GUI customizable using something CSS-ish. In (X)HTML, almost all elements in the body are interchangeable, they just come with different default style sheets, and while I would certainly have defined a different set of elements with different default style sheets compared to (X)HTML, the principle would be the same. And I would of course use a different scripting language, probably Lua and/or Scheme, possibly Java (as scripts, using BeanShell, not as compiled jars).
Posted Oct 19, 2012 7:55 UTC (Fri)
by jezuch (subscriber, #52988)
[Link]
http://sourceforge.net/projects/jaxx/
I did my engineering thesis in this, way back before it went dead ;) It was pretty cool, especially the CSS-like declarations and binding expressions, but the implementation was *horrible*.
Posted Oct 17, 2012 10:41 UTC (Wed)
by union (guest, #36393)
[Link] (5 responses)
The only toolkit that comes close is QT, because you can use QML witch is close to web technologies.
And the biggest problem javascript has is that people don't take time to learn it properly, they just copy-paste broken code from ten years old tutorials they find on the web. If you take time and learn language properly (like you would do with oter languages), you know what features work and what to stay away from, and then it suddenly becomes decent language (at least for frontend).
Posted Oct 17, 2012 11:55 UTC (Wed)
by ms (subscriber, #41272)
[Link] (4 responses)
IMO, your last statement, "it suddenly becomes decent language (at least for frontend)" is key - yes, if you are just doing inversion of control, and just wiring simple actions off elements, then JS is fine. As soon as you start doing anything heavier, it becomes horrific. However, it's not clear to me where the problems are JS's own fault and where they're library/implementation issues. For example, the CPS mess that results due to a lack of threading: as soon as you start doing any real IO, any semblance of control flow you thought you had has rendered your code to a mess of spaghetti. But the ECMAScript 5 spec is, IIRC, silent on the issue of threading and IO in general. The many definitions of bottom (false, undefined, null), the endless variations of implementations, the endless duck typing and random heuristics and general lack of any degree of confidence that different libs will actually work together - there is no static way of validating that one library will not do things that are thoroughly incompatible with other libraries. NodeJS certainly exacerbates these problems to the Nth degree, but they're there in the browser too.
The issue about learning the language "properly" is that it's difficult to when certain aspects of the language (e.g. the "new" operator) were put there deliberately to "lower the learning curve" but serve merely to confuse. As you say, if you know what to stay away from then it perfectly fine, but then the same is said of Perl. And complex Perl might actually be more readable than complex JS! Once you have learnt the language properly, you realise how significant the lack of sensible language features really is; the threading issues in particular. Promises and friends help to a degree, but really you just can't write large maintainable code bases that do anything particularly complex. Now if you thus treat JS as a DSL for the browser, that might be ok, provided you don't try and do anything too complex in the browser (though the C-like webGL is clearly complex from the exact opposite end of the spectrum!). But firstly people want to do more and more in the browser, and secondly, JS keeps being used as a more general purpose language outside of the browser, which just strikes me as odd.
HTML is fine as a document structuring DSL when you actually get to use it for that, but most new single-page-apps start with a blank HTML file just loading scripts, and all DOM elements are constructed programmatically from the JS. Programmatic construction of GUIs is (IMO) a poor idea at best because it tends to put off anyone with any actual design skills from being involved. Graphical design of GUIs makes a whole lot more sense, at least to me, though I'm aware this is another can of worms that I don't really want to open! I remember in the 1990s writing applications under RISC OS. The graphical GUI designer, !WinEd (http://www.riscos.info/index.php/WinEd) was superb and I have not worked with anything that makes GUI design so intuitive and simple since (having done bits or more from ncurses, Java Swing/AWT and Java SWT, and HTML/CSS/JS amongst others).
Posted Oct 17, 2012 12:39 UTC (Wed)
by drag (guest, #31333)
[Link] (3 responses)
Posted Oct 17, 2012 12:50 UTC (Wed)
by ms (subscriber, #41272)
[Link] (2 responses)
Posted Oct 17, 2012 12:56 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 17, 2012 13:01 UTC (Wed)
by drag (guest, #31333)
[Link]
Worse is better.
Why is windows dominate on the desktop? Why did Unix beat out other much better optimized systems? Why did Linux become the most popular posix-y system when it's full of so many idiosyncrasies and the BSD OSes were technically superior for many years early on and were just as free?
etc etc.
The answer is that implementation differences in technology pale in importance when compared to external factors and realities.
:)
The corollary to this is that technical superiority isn't going to do much for you in terms of marketability nor usefulness for your target users and developers. Ignore external realities at your peril.
:P
Posted Oct 17, 2012 11:10 UTC (Wed)
by canatella (subscriber, #6745)
[Link] (2 responses)
- development cycle is easy and the tools are there,
2 years ago I was cursing against it but now, with html 5, they're actually making developers life simpler. There is still the problem that you have to design the look of your application while using toolkits you don't have to but then there exists design that you can reuse and it might also be considered as a plus by some.
Posted Oct 17, 2012 11:41 UTC (Wed)
by nye (subscriber, #51576)
[Link] (1 responses)
I generally agree that JS gets a bad rap, but there are problems with it that go beyond problems with any particular implementation - some part of the language itself are distressingly bad.
The exact behaviour of its semicolon insertion, in particular, is unforgivable.
Posted Oct 19, 2012 8:10 UTC (Fri)
by jezuch (subscriber, #52988)
[Link]
I don't know. I never had to think about it while writing code. For me this means that it's rather decent.
Much, much, MUCH worse is how all numbers are half-float, half-integer (with limited precision, IIRC). That's just... unspeakable.
But, other than that, I rather like this little bugger.
Posted Oct 17, 2012 12:08 UTC (Wed)
by Lennie (subscriber, #49641)
[Link]
And maybe Javascript is like Basic, it looks like it is easy to learn (but it has lots of parts you should never ever use -> see the book: Javascript the good parts or listen to a talk from the author).
The web has one dominant scripting language, as you probably know pretty much every part of computing always gravitates to adopting one or very few system languages, desktop operating systems and word processor document formats, routing protocols and so on. Or in this case scripting language.
But I don't think Lua syntax-wise is all that much better than Javascript either. It isn't technically that much better for the user of the scripting language that they see a reason to learn a new language.
The developer which needs to implement the embedding obviously can see the advantage (easier and uses less memory and maybe even a little bit less CPU time).
Posted Oct 17, 2012 12:35 UTC (Wed)
by drag (guest, #31333)
[Link]
I don't care one what or the other what language they have used.
They have chosen it because it is very popular language that is familiar with the largest number of possibly interested people, it's standardized, and ties into other technologies they are leveraging.
The point is that it's completely scriptable, so whatever type of window manager functionality you want you can spend your time concentrating on writing the functionality rather then writing a window manager.
But to each their own. If you want to write a new one from scratch then go for it.
Posted Oct 17, 2012 19:38 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Oct 17, 2012 21:03 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
Some traits it shares one of the most successful languages ever, C. Another shared trait is that it's almost everywhere: your browser can run it, so the only other thing you need to experiment is a text editor (and some documentation). Maybe other languages are better (Lua, Ruby), but JavaScript is just more convenient.
Posted Oct 17, 2012 23:41 UTC (Wed)
by man_ls (guest, #15091)
[Link] (8 responses)
Of course it is possible to do aberrations against Nature in it, but that is true of all languages. Lua is a bit horrible too once you get to meta-tables. The object model in particular is awful; the good thing is that you can build your own with a few lines of code.
In summary: in JavaScript, you take an empty object, tell it "you are a chicken now", stick a beak, legs and some feathers on it, and it goes away clucking like crazy.
Posted Oct 18, 2012 22:27 UTC (Thu)
by alonz (subscriber, #815)
[Link] (1 responses)
Posted Oct 19, 2012 0:17 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 22, 2012 3:32 UTC (Mon)
by cmccabe (guest, #60281)
[Link] (5 responses)
I agree that duck typing is one thing that ECMAScript got right. However, Golang (Google Go) is able to do this without giving up static typing. I think that's the way to go... no pun intended. :)
Posted Oct 22, 2012 7:52 UTC (Mon)
by man_ls (guest, #15091)
[Link] (4 responses)
For some applications a single-process server may not be right, but for the rest convenience usually trumps performance. (Witness MongoDB beating Riak or Cassandra.) Amazon rents cheap two-core servers, very convenient to run node.js on. In fact node.js uses two cores: one for receiving requests and another for servicing them.
There are a couple of ways around a single-process server on a multi-core machine. One is to run many stateless node.js processes on a server. Another is to modify the V8 engine to run many threads in the same process and synchronize them; it is a more definitive solution, even though the engineering costs may be high. I don't doubt that Google can make it if they try.
Posted Oct 22, 2012 7:53 UTC (Mon)
by man_ls (guest, #15091)
[Link]
Posted Oct 25, 2012 9:34 UTC (Thu)
by cmccabe (guest, #60281)
[Link] (2 responses)
Personally I find the claims of "orders of magnitude faster than other traditional servers" pretty hard to swallow, but such claims are also "traditional" in their own way, so who am I to complain? :)
> For some applications a single-process server may not
It doesn't really make sense to compare Cassandra to MongoDB and Riak, since traditionally Cassandra is used with a much weaker consistency model.
Posted Oct 25, 2012 9:38 UTC (Thu)
by man_ls (guest, #15091)
[Link] (1 responses)
Posted Oct 30, 2012 15:55 UTC (Tue)
by cmccabe (guest, #60281)
[Link]
Note to nitpickers: a lot of these datastores can be configured to run in different consistency modes. For example Riak has last_write_wins, and Cassandra has the ability to do quorum writes, etc. In general, though, if you find yourself obsessing over these settings, you might just be using the wrong datastore for the job. They have different design goals.
To come back to your particular situation, denormalizing the data that you store in MongoDB is a choice that you have made. You could do the same thing with SQL, or any other strongly consistent data store.
On the other hand, you could say that the limtiations MongoDB forced you to go down this path, since it doesn't support SQL-style transactions, foreign keys, and so forth. That's a fair point.
Posted Oct 22, 2012 3:18 UTC (Mon)
by cmccabe (guest, #60281)
[Link]
Rather than "using scripting to make something do whatever," why wouldn't I just write my own window manager?
Also, I hope you realize you've doomed us to tedious discussions of whether or not Javascript is a good language, or whether GNOME3 is a good desktop environment. The only way your comment could have been more inflammatory is if you had mentioned network transparency... :)
Posted Oct 16, 2012 23:26 UTC (Tue)
by Zizzle (guest, #67739)
[Link] (25 responses)
Posted Oct 16, 2012 23:33 UTC (Tue)
by shmerl (guest, #65921)
[Link] (23 responses)
Posted Oct 17, 2012 2:02 UTC (Wed)
by set (guest, #4788)
[Link] (4 responses)
Posted Oct 17, 2012 8:09 UTC (Wed)
by drag (guest, #31333)
[Link] (3 responses)
Mind you this is purely as a end user. I just wanted something that worked the best with the least amount of time and effort I could put into it.. because I did not have much time at all.
The remote system was a Debian VM being set up as a XFCE desktop on a CentOS 6.2 host running on the far side of a large corporate network. I tried out NomachineX, Spice, X windows, and various VNC incarnations. Most VNC stuff pretty much sucked, but running a Xvnc/TigerVNC was impressive. In terms of low latency, visual quality, and things like 'copy-n-paste' working properly it was the best I could find and setup in my limited time.
http://www.tigervnc.org/cgi-bin/rfbproto
The RFB protocol is very simple and if Wayland can take advantage of those sorts of optimizations that TigerVNC uses when combined with per-application buffers and proper compositing on local and remote systems... then that would be probably be a huge winner.
If they can combine that with how Spice is able to detect video and compress sections of the display to a streaming codec like MJPEG, then I think that Wayland remote desktop/applications could be a thing of beauty.
Posted Oct 17, 2012 15:02 UTC (Wed)
by shmerl (guest, #65921)
[Link] (1 responses)
Posted Oct 17, 2012 17:29 UTC (Wed)
by drag (guest, #31333)
[Link]
Posted Oct 18, 2012 12:05 UTC (Thu)
by lindi (subscriber, #53135)
[Link]
Posted Oct 17, 2012 17:34 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (17 responses)
Posted Oct 17, 2012 19:42 UTC (Wed)
by njs (subscriber, #40338)
[Link] (15 responses)
xpra solves the detach/reattach part for X, but I'm pretty sure it hasn't implemented forwarding for the notification bar protocols.
Posted Oct 17, 2012 20:09 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link]
Posted Oct 17, 2012 20:31 UTC (Wed)
by ncm (guest, #165)
[Link] (13 responses)
Posted Oct 19, 2012 14:28 UTC (Fri)
by drag (guest, #31333)
[Link] (12 responses)
1. Graphic outputs over the network (as discussed above)
I would be happy when 1 and 3 since I can fudge PA to work well for 2 and I have no problem with scp. I am just saying since this is the sort of functionality people expect to be present for remote desktops since it's already present in most competing products.
Posted Oct 19, 2012 15:02 UTC (Fri)
by njs (subscriber, #40338)
[Link] (3 responses)
Sane *async* protocol for cut-and-paste format negotiation/data transfer
Custom cursor updating
Communicating desktop geometry (including multiple monitors at different resolutions, etc.)
Relationships between windows ("this window is a modal pop-up to that window")
Mapping windows to processes ("this process appears to have frozen; kill it?")
etc. There's just a ton of fiddly details like this.
Posted Oct 25, 2012 4:14 UTC (Thu)
by amtota (guest, #4012)
[Link] (2 responses)
Posted Oct 25, 2012 11:36 UTC (Thu)
by njs (subscriber, #40338)
[Link] (1 responses)
I know (I wrote it, remember ;-)), but last I checked it required a horror-show of manually tracking nested GTK mainloops. (Actually I'd love to see the code if you've managed to fix that.) My point was that who-ever's doing Wayland remoting stuff should try to avoid getting stuck with such nonsense.
> xpra tries to do that (not easy - not even do-able in some cases since we cannot tell the client's window manager to "group" windows together so they move together - but we manage ok)
Actually I think you probably do support the example I gave in this message (attaching a modal pop-up to its parent), since that's in ICCCM/EWMH; its menus and other override-redirect stuff that's really broken in X.
> > Mapping windows to processes ("this process appears to have frozen; kill it?")
This is really easy actually, see _NET_WM_{PING,PID,HOSTNAME) (IIRC); I'm pretty sure there's some vestigial support in the code already. The only tricky part is giving it a useful UI on the client side, but you have a systray applet to hang UI off of now, right...?
Posted Oct 26, 2012 3:58 UTC (Fri)
by amtota (guest, #4012)
[Link]
> horror-show of manually tracking nested GTK mainloops
> (...) its menus and other override-redirect stuff that's really broken in X.
> This is really easy actually, see _NET_WM_{PING,PID,HOSTNAME) (IIRC);
Posted Oct 25, 2012 4:08 UTC (Thu)
by amtota (guest, #4012)
[Link] (7 responses)
Posted Oct 25, 2012 13:34 UTC (Thu)
by njs (subscriber, #40338)
[Link] (6 responses)
In principle even this would be fixable with some work (either by fixing the PA TCP mode or by running a PA daemon on the server and loading some custom 'xpra sink'), but the real problem is multiplexing latency-sensitive audio + screen updates over an SSH channel over TCP while avoiding audio dropouts. Maybe once bufferbloat is fixed this will be more doable, but for now it's a very difficult bit of network engineering.
> xpra supports ssh and will have an AES/SPEKE secure tcp mode in the next release (probably)
While I am sort of amused to see my predictions from years ago coming true[1], it's still true that ROLLING YOUR OWN TRANSPORT CRYPTO IS A STUPID IDIOTIC IDEA AND YOU SHOULD NOT DO IT. Sorry for shouting, but it is important that you NOT DO THIS IT WILL NOT BE SECURE I PROMISE YOU WILL BE LYING TO YOUR USERS. I know SSH and TLS are both obnoxious to work with but EVERYTHING ELSE IS SNAKE OIL THERE IS NO-ONE ALIVE WHO IS SMART ENOUGH TO DO WHAT YOU ARE DOING SO STOP IT.
...goodness sakes, 2 minutes of googling suggests that TLS-SRP is even reasonably well supported these days. Use that. Please.
[1] "how do I know that the next person won't want even more assurances, like encryption or MITM protection or whatever? That will *definitely* spiral out of our ability to get right." - http://lists.partiwm.org/pipermail/parti-discuss/2009-Jun...
Posted Oct 26, 2012 3:50 UTC (Fri)
by amtota (guest, #4012)
[Link] (5 responses)
> ROLLING YOUR OWN TRANSPORT CRYPTO IS A STUPID IDIOTIC IDEA AND YOU SHOULD NOT DO IT. Sorry for shouting (...)
> I know SSH and TLS are both obnoxious to work with (...)
> EVERYTHING ELSE IS SNAKE OIL (...)
> That will *definitely* spiral out of our ability to get right."
Posted Oct 26, 2012 14:17 UTC (Fri)
by njs (subscriber, #40338)
[Link] (4 responses)
This is only useful if you can convince as many people to review your code as have reviewed SSH/TLS. Those protocols both contained bugs which survived dozens of man-years of review. You are not smarter than the entire cryptographic community. Have you read your Ferguson & Schneier (& Kohno)? What's your rekeying time? Do you know what that is and why it matters? Now that I've said that you can look it up and patch one obvious hole, but there will still be a dozen more.
> I think the authors of SPEKE would beg to differ...
WTF, do you not even understand the difference between a crypto primitive and a crypto protocol? SPEKE is a fine primitive (well, there are better ones, but that's actually besides the point). But it doesn't matter if you choose good primitives. If design your own protocol YOU WILL FUCK IT UP AND CHALLENGING PEOPLE TO REVIEW IT WILL NOT SAVE YOU.
Most snake oil vendors honestly believe that their code is great! And advertise them by boasting about using cool primitives (AES! SPEKE! XX-bits! never mind that they're used insecurely!). And then when someone point this out, the snake oil vendor always responds by challenging them to review the code and point out specific problems. Srsly you're exhibiting the classic symptoms. Stop and think about it. Spreading bad crypto is a sin.
> Please do consider the differences between the ssh/tls model and speke
Please read my fucking message. I said you should use TLS-SRP. That has the same model as the protocol you are ineptly trying to design. Yes, it requires you to deal with the gnutls api instead of playing around with fun maths, but on the other hand IT IS DESIGNED AND IMPLEMENTED BY PEOPLE WHO KNOW WHAT THEY ARE DOING AND IT WILL ACTUALLY FUCKING WORK.
(Just one example - SPEKE requires the server store passwords in plain text, which we've had *plenty* of evidence lately is a terrible idea. SRP avoids this problem.)
Posted Oct 27, 2012 1:45 UTC (Sat)
by amtota (guest, #4012)
[Link] (3 responses)
Posted Oct 27, 2012 10:11 UTC (Sat)
by njs (subscriber, #40338)
[Link]
Obviously though if you are determined not to listen when people warn you that you are making a serious mistake, then that's ultimately your decision.
Posted Oct 28, 2012 17:31 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Feb 19, 2015 1:34 UTC (Thu)
by gmatht (guest, #58961)
[Link]
Posted Oct 20, 2012 2:46 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 16, 2012 23:58 UTC (Tue)
by shmerl (guest, #65921)
[Link]
Posted Oct 17, 2012 20:21 UTC (Wed)
by ncm (guest, #165)
[Link]
Wayland and Weston 0.99.0 snapshots released
API freeze
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
- with html and javascript you already have view and controller enforced,
- css is way more flexible then having to spec all padding and margins in code,
- graphical designer can focus on ui design, you focus on code.
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
JavaScript ubiquity
This "let's do everything in JavaScript" trend at the moment is a curious thing. I can't believe anyone with any experience of any sane language would actually want to write in JS - it's more just that it's pretty much the only choice for web apps.
It is interesting to me also; one year ago I would not have thought it possible. It is hard to know what you mean by "sane language"; I have a background in C, Java, Python and a few other languages, and after a while I find JavaScript a great language. It is extremely simple, it is very expressive (and functional), and it can do lots of things with very little code: for example, node.js does the main loop in js code, not in some awful native library.
Hey, I thought JavaScript had duck typing! Now you're telling me it's been chicken typing all along?
JavaScript ubiquity
;)
In my experience it's more like duct taping. But it works. Usually.
JavaScript ubiquity
JavaScript ubiquity
Somehow I don't think so: node.js is already orders of magnitude faster than other traditional servers. Also, I don't see all Python people throwing away their twisted servers, or Ruby throwing away Rails; and node.js is much more convenient than those two.
JavaScript ubiquity
A relevant reference for R. It can be done.
JavaScript ubiquity
JavaScript ubiquity
> be right, but for the rest convenience usually trumps
> performance. (Witness MongoDB beating Riak or Cassandra.)
I don't understand the bit about "weaker consistency model". I am using MongoDB with a very weak consistency model: data is denormalized (there are several copies of each piece of data, in different collections) and I have to ensure consistency in my application code. Why is it different with Cassandra or Riak?
JavaScript ubiquity
JavaScript ubiquity
Wayland and Weston 0.99.0 snapshots released
> a person can use javascript to make it do whatever and
> in any manner they wanted.
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
2. Audio output over the network (TCP support in Pulseaudio is very effective)
3. Copy-n-paste over the network. Hopefully some standard for clipboard managers will be implemented. Hopefully HTML-aware in a manner similar to Windows.
4. Notifications over the network.
5. File transfer support.
6. Some sort of thing for supporting weird input devices. Like USB support for generic devices.. things for special input support like game devices or accessability devices. I don't know.
7. Some lovely way to securely tunnel it all. SSH would be great I expect.
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
xpra.org deals with graphics and dbus notifications.
dbus was not designed to be networked however, so forwarding any more dbus based protocols would need to be done on a per case basis unfortunately.
As for audio, see my other reply: PA is not suitable without a fair amount of work (compression, support for disconnection, etc)
> Sane *async* protocol for cut-and-paste format negotiation/data transfer
xpra does that (mostly reasonably well too now)
> Custom cursor updating
xpra does that
> Communicating desktop geometry (including multiple monitors at different resolutions, etc.)
Planned.
> Relationships between windows ("this window is a modal pop-up to that window")
xpra tries to do that (not easy - not even do-able in some cases since we cannot tell the client's window manager to "group" windows together so they move together - but we manage ok)
> Mapping windows to processes ("this process appears to have frozen; kill it?")
Not supported yet (hard I think)
> etc. There's just a ton of fiddly details like this.
Indeed!
Wayland and Weston 0.99.0 snapshots released
>xpra does that (mostly reasonably well too now)
> Not supported yet (hard I think)
Wayland and Weston 0.99.0 snapshots released
Hah, hi Nathaniel! (aka 'njs')
It's still there :(
I wanted to replace it with something more like twisted's "deferred", but haven't got around to it. There were a number of issues in the clipboard code, but this one has not risen to the top of the never ending todo list yet..
Yes, what we've added is more of a hack for OR menus, to ensure they move with their parent.
> I'm pretty sure there's some vestigial support in the code already. The only tricky part is giving it a useful UI on the client side, but you have a systray applet to hang UI off of now, right...?
Yes, and it is planned. A related, and more urgent work item along those lines is dealing with dropped connections so that the client windows start showing the user that something is wrong before they start clicking repeatedly on a window which is no longer connected to its server, or not responding. (greying them out or something)
network-ability Wayland should have: most of those are in xpra
See xpra.org
> 2. Audio output over the network (TCP support in Pulseaudio is very effective)
I beg to differ, it is very bandwidth heavy, around 4MBps by default.
xpra supports that (setting up the X11 cookie etc), but it would need audio compression to be really useful. Also, the default pa tcp mode does not support disconnection/re-connection...
> 3. Copy-n-paste over the network. Hopefully some standard for clipboard managers will be implemented. Hopefully HTML-aware in a manner similar to Windows.
xpra does that
> 4. Notifications over the network.
xpra does that - tray icon support is planned
> 5. File transfer support.
Not implemented - not sure we want to either.
> 6. Some sort of thing for supporting weird input devices. Like USB support for generic devices.. things for special input support like game devices or accessability devices. I don't know.
On the todo list so we can support things like pressure sensitive devices over the network (ie: android clients)
> 7. Some lovely way to securely tunnel it all. SSH would be great I expect.
xpra supports ssh and will have an AES/SPEKE secure tcp mode in the next release (probably)
network-ability Wayland should have: most of those are in xpra
network-ability Wayland should have: most of those are in xpra
In winswitch, I've solved this by doing pretty much that: starting a decicated PA server per session (which is not trivial if you launch more than one per user) and then compressing the stream over TCP sockets (yikes) via gstreamer pipelines (with buffering and all)
The problem with xpra is that I see this as being out of scope: do one thing and do it well.
Please feel free to review the code once it is finished (it isn't), some already have already provided comments:
https://www.xpra.org/trac/ticket/198
Indeed. And more importantly, it is a different security model altogether: one where you trust an authority (or just inspect manually) to verify the authenticity of the host. We aren't interested in that. If that is what you want, stick with SSH, or use OpenVPN.
I think the authors of SPEKE would beg to differ...
Well, let's agree to disagree. Secure key exchange is not rocket science, it was quite a new thing 15 years ago, but things have moved on.
Please do consider the differences between the ssh/tls model and speke.. these do not address the same concerns. (and I'll admit there may well be difficulties in explaining those differences to users)
network-ability Wayland should have: most of those are in xpra
network-ability Wayland should have: most of those are in xpra
Sorry, after all the shouting and swearing, I stopped. Maybe some other time.
network-ability Wayland should have: most of those are in xpra
network-ability Wayland should have: most of those are in xpra
Minus the shouting the concern seems to be that your security model sounds a lot like that of the already existing TLS-SRP (as opposed to plain TLS). For example:
TLS-SRP (as opposed to plain TLS) is suitable?
TLS-SRP provides mutual authentication (the client and server both authenticate each other), while TLS with server certificates only authenticates the server to the client. Client certificates can authenticate the client to the server, but it may be easier for a user to remember a password than to install a certificate. -- Wikipedia
Any comments on the difference between your security model and that of TLS-SRP?
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released
Wayland and Weston 0.99.0 snapshots released