Update

As you may have heard, a number of hackers from the DeBiAn and wiLleRz groups
have acquired what they are claiming is the Y-windows source code.

Since then they have placed modified versions on a number of public websites. 
The number of similarities to the official codestream allows us to be certain
that they have had access to the official code.

Obviously we are concerned by this leak.  We are currently conducting an
internal investigation to determine how this happened, and we are scheduling
meetings with our attorneys to determine if a legal response is appropriate.

In the meantime, I must urge you all to avoid these pirate versions; our
intellectual property is the only asset we have, and your help in protecting it
would be appreciated.

You will be pleased to hear that this will not affect the release schedule for
project Escargot (version 1.0).

Thank you for your assistance in this matter,

Phil, on behalf of the Y-windows development team

Re: Update

On Fri, 2005-04-01 at 23:10 +0100, Phil Willoughby wrote:
> As you may have heard, a number of hackers from the DeBiAn and wiLleRz groups
> have acquired what they are claiming is the Y-windows source code.
> 
> Since then they have placed modified versions on a number of public websites. 
> The number of similarities to the official codestream allows us to be certain
> that they have had access to the official code.
> 
> Obviously we are concerned by this leak.  We are currently conducting an
> internal investigation to determine how this happened, and we are scheduling
> meetings with our attorneys to determine if a legal response is appropriate.

Leak?  What leak?  Isn't Y-windows licensed under the LGPL?  Isn't the
Y-windows source code publicly available?  The only possible
interpretation I can think of is that they have relicensed the Y-windows
source code under something other than the LGPL or GPL.

> 
> In the meantime, I must urge you all to avoid these pirate versions; our
> intellectual property is the only asset we have, and your help in protecting it
> would be appreciated.

As a free software developer, I find your terminology offensive.
(Specifically, "intellectual property" and "pirate".)

> 
> You will be pleased to hear that this will not affect the release schedule for
> project Escargot (version 1.0).

What is project Escargot?  What does it have to do with Y-windows?

Re: Setup of a nothing - the userbase strength matters not?

Em Sexta, 1 de Abril de 2005 23:12, o y-devel-request <at> y-windows.org escreveu:
> > 3: Occasionally I get bored of films and play music instead.
>
> Nobody needs a GUI for that.

 Yep. I use this simple tool made by myself for that purpose:
http://rpmcruz.planetaclix.pt/trash/splayer.tgz

 You just need the SDL_mixer library installed, as well as the headers for 
compilation.
 It doesn't support pretty stuff like a playlist, but it does its ugly job of 
playing musics rather well. See the README for examples of usage.

Cheers for Y,
 Ricardo Cruz
--

-- 
This is a test of the Emergency Broadcast System.  If this had been an
actual emergency, do you really think we'd stick around to tell you?

Re: Update

Phil Willoughby wrote:
> As you may have heard, a number of hackers from the DeBiAn and wiLleRz groups
> have acquired what they are claiming is the Y-windows source code.
> 
> Since then they have placed modified versions on a number of public websites. 
> The number of similarities to the official codestream allows us to be certain
> that they have had access to the official code.

Aha, I knew you guys had a secret source tree that no one new about or
has seen!  I'll bet you guys are almost done with Y, huh?

> Obviously we are concerned by this leak.  We are currently conducting an
> internal investigation to determine how this happened, and we are scheduling
> meetings with our attorneys to determine if a legal response is appropriate.
> 
> In the meantime, I must urge you all to avoid these pirate versions; our
> intellectual property is the only asset we have, and your help in protecting it
> would be appreciated.
> 
> You will be pleased to hear that this will not affect the release schedule for
> project Escargot (version 1.0).

Good, I'm glad the development is on schedule.  Source leaks can have
such a detrimental effect on plans.  When exactly is Escargot expected
to be released?  First quarter 2006?

Matt

Re: Update

This is somewhat related: Did you hear that gmail is now offering
infinity+1 gigabytes of storage space?!?

Welcome to the new month everyone. (the month being April, and the day
being the 1st)

Re: Update

Re: Update

I allready sent this last night, but forgot to CC to list :)

On Fri, 2005-04-01 at 17:37 -0500, Ben Urban wrote:

> Leak?  What leak?  Isn't Y-windows licensed under the LGPL?  Isn't the
> Y-windows source code publicly available?  The only possible
> interpretation I can think of is that they have relicensed the Y-windows
> source code under something other than the LGPL or GPL.

* looks @ date...
* whistles...
* carries on...

--

-- 
Regards,
Mathy Vanvoorden

bytecode modules

Hello,

I'm writing to get some feedback on an idea that I came up with today.

The reason why I've been thinking about it is because I think thin clients are 
pretty nifty things. But better software is needed to make them more useful.

I see three options to get the look and feel of your desktop environment no 
matter what terminal you happen to sit in front of.

* A VNC-like system plugged in as video and input driver.
  - Latencies. No better than X.
  + Pure plugin, doesn't require changes to the server.

* Standalone clients for things that affect L&F (theme, wm...) communicating 
  through proxy plugins or special method invokations in the Y protocol.
  - Latencies. No better than X.
  + Possible as pure plugin.

* Bytecode or script for L&F modules.
  - Performance.
  - Requires changes to the server and lots of work.
  + No network latency.
  + Security, no theme plugins with spy-ware or other crap.

Here I'm arguing that designing a bytecode for theme/wm/widgets modules is a
good idea.

For security (and laziness) reasons the bytecode should only consist 
of instuctions that a theme, widget or window manager needs to use.

I'm guessing (very much guessing) performance wouldn't suffer all that much
since the instructions would be on a very high level, e.g. drawLine(), and thus
most execution would be native. Themes with thousands of putPixel() calls have
themselves to blame...

Being able to write widgets in bytecode would make life easier when a new 
version of Y contains a new widget. New apps could provide the widget 
themselfs if running on an old server lacking this widget. At least it's a 
better fallback than implementing the new one on a canvas.

Artistic non-programmers would get an easier, dedicated language to write themes 
in.

This solution removes (or at least decreases) the need for a stable internal 
api.

A program drawing the desktop (root window) should be a client since it most 
probably will want to load images from remote harddrive.

Curious to hear what people have to say about this.

/Simon

Re: bytecode modules

On Mon, 2005-04-04 at 09:58 +0200, simper-2 <at> student.ltu.se wrote:
> Hello,
> 
> I'm writing to get some feedback on an idea that I came up with today.
> 
> The reason why I've been thinking about it is because I think thin clients are 
> pretty nifty things. But better software is needed to make them more useful.
> 
> I see three options to get the look and feel of your desktop environment no 
> matter what terminal you happen to sit in front of.
> 
> * A VNC-like system plugged in as video and input driver.
>   - Latencies. No better than X.
>   + Pure plugin, doesn't require changes to the server.
> 
> * Standalone clients for things that affect L&F (theme, wm...) communicating 
>   through proxy plugins or special method invokations in the Y protocol.
>   - Latencies. No better than X.
>   + Possible as pure plugin.
> 
> * Bytecode or script for L&F modules.
>   - Performance.
>   - Requires changes to the server and lots of work.
>   + No network latency.
>   + Security, no theme plugins with spy-ware or other crap.
>   
> Here I'm arguing that designing a bytecode for theme/wm/widgets modules is a
> good idea.

What a perfect job for Python!  It's certainly a well-established
language, and it already uses bytecode.

> 
> For security (and laziness) reasons the bytecode should only consist 
> of instuctions that a theme, widget or window manager needs to use.

I'm not sure how security might work in Python.  Perhaps someone else on
this list has some ideas about that?  One thought would be to remove
access to any other modules.  I'm not sure Python can do that easily,
but it's worth looking into.  (Keep in mind that any other Python
implementation already on the system must still work as expected.)

> 
> I'm guessing (very much guessing) performance wouldn't suffer all that much
> since the instructions would be on a very high level, e.g. drawLine(), and thus
> most execution would be native. Themes with thousands of putPixel() calls have
> themselves to blame...

Python works very well with native modules, so this wouldn't be a
problem.

> 
> Being able to write widgets in bytecode would make life easier when a new 
> version of Y contains a new widget. New apps could provide the widget 
> themselfs if running on an old server lacking this widget. At least it's a 
> better fallback than implementing the new one on a canvas.
> 
> Artistic non-programmers would get an easier, dedicated language to write themes 
> in.
> 
> This solution removes (or at least decreases) the need for a stable internal 
> api.
> 
> A program drawing the desktop (root window) should be a client since it most 
> probably will want to load images from remote harddrive.
> 
> 
> Curious to hear what people have to say about this.
> 
> /Simon
> 
> 
> 

Disclaimer:  I love Python (can't you tell?)

Re: bytecode modules

On Mon, Apr 04, 2005 at 08:20:39AM -0400, Ben Urban wrote:
> On Mon, 2005-04-04 at 09:58 +0200, simper-2 <at> student.ltu.se wrote:
> > Here I'm arguing that designing a bytecode for theme/wm/widgets modules is a
> > good idea.
> 
> What a perfect job for Python!  It's certainly a well-established
> language, and it already uses bytecode.

So does java. And BCPL. And probably a few others. I think you have just
put the people that have strong ideas about clean code off this idea for
good. And all it took was mention your pet language where it was not
needed.

Besides, any general bytecode is about the worst you can put in. It'll
get you a free express ticket to the wonderful world explored at large
by micros~1 with their vb-in/on/through-anything *cough* enhancements.

What you _need_ is, as OP said, something restricted to what things on
your screen do. OpenGL primitives or somesuch. Not another virus engine.

> Disclaimer:  I love Python (can't you tell?)

Do you have any idea how annoying it is discussing _anything_ with
lovesick people?

alt.lang.python.wuv.wuv.wuv is ---------------------> thataway.

--

-- 
  j p d (at) d s b (dot) t u d e l f t (dot) n l .