Hacker Timesnew | past | comments | ask | show | jobs | submit | froseph's commentslogin

One I dont see mentioned is Xnest (or its successor Xephyr). In a previous life, used it all the time to debug apps in multiple desktop environments.


Good one.

I recall, around 2004, using it on Windows, under Cygwin, to run cygwin-compiled X apps on Windows.

I'm not sure how that worked at all, to be honest. I hope my memory is not playing tricks on me again.


My (less-than-half-baked) master's thesis has a screenshot of Xnest, which I was using to demonstrate some ridiculously primitive precursor to kernel namespaces, IIRC


I like xvfb-run which runs GUI X11 applications in a headless mode.


One of my favorite bits of software is Xpra [0], "screen for X". You'd run it and it would start another X server (start apps in it with `DISPLAY=:1 xterm` or whatever), and you would "attach" it to your running X server with `xpra attach`.

You can attach to e.g. `ssh://hostname/:1`, so I ran a firefox instance on a homelab server and attached to it from my laptop and my desktop to not have to bother keeping bookmarks, tabs etc in sync.

[0] https://xpra.org/


I do lots of small commits as save checkpoints and new branches for each point of exploration. Rebase/reset to create clean commits. Each final commit is a complete thought.


Yeah sometimes the small commits with message is useful for me too instead of amending a big accumulated check. Doing this now, in fact. It's all so situation dependent.


My favorite article on the life cycle (growth & collapse) of online communities is “Attacked from Within”* from the old kuro5hin site. I’ve always been curious to how it’s suggested solutions to the moderation problem would turn out.

* Archived here: http://atdt.freeshell.org/k5/story_2009_3_12_33338_3000.html


It's giving me a 502 bad gateway :(


...fixed


The wayback machine* has Zachary Amsden's opinion in 2007 why the vmkernel (and other components) are not in violation of GPL. It's an interesting read.

He concludes:

> 1) There is no argument that depending on a Linux console OS makes any part of ESX subject to GPL that is not already opene sourced. We have open sourced those GPL components of the system which we have modified and given the changes back to the community.

> 2) There is no argument that loading the vmkernel by bootstrapping it with Linux makes the vmkernel subject to GPL. In fact, in the funniest counter-example, Linux itself used to be boostrapped under MS-DOS by running the command loadlin (note the 7 character name, since DOS would not allow enough characters for load-linux).

> 3) There is no argument that distributing GPL binary drivers makes any piece of software distributed with them or using them subject to GPL. In fact the converse appears to be explicitly stated in the GPL itself.

* http://web.archive.org/web/20080105204946/http://www.venture...

updated for formatting.


Points (1) and (2) aren't relevant - nobody in this case is making those arguments. Point (3) is more interesting. He makes three arguments there.

1) The GPL doesn't cover execution, only distribution

True, and as such an end user loading a proprietary kernel driver into a GPLed kernel (or vice versa) isn't infringing. But things get more complicated when you're distributing a product that consists of GPLed and proprietary code and requires both of them to be useful. If vmkernel is basically useless without vmklinux, there's a reasonable argument that the distributed product is a derived work of both vmkernel and vmklinux.

(The same argument doesn't apply to a product using proprietary applications on top of the Linux kernel - there's an explicit statement in the Linux copyright file that using the standard userspace interfaces doesn't create a derived work)

2) There's a copyright boundary between Linux and kernel modules

Quoting from his comment:

"Linux has established a well defined, binary interface through which driver modules and the kernel may interact, with well defined copyright separation."

This is, well, nonsense. Calling the Linux kernel ABI well-defined is entirely untrue - it changes rapidly between releases, it changes within releases (there's no guarantee that an LTS kernel will keep the same ABI between minor point releases) and even Red Hat, who expend a huge amount of effort on maintaining a stable kernel ABI, only make their kABI guarantees for a small subset of the actual kernel ABI.

3) Nobody complaining about this has any standing

"those vocal advocates such as Christoph, who are so offended by this, do not even own any copyright on the code we are distributing"

I'll be charitable and chalk this up to being misinformed rather than an outright lie.

There is certainly an argument that distributing GPL drivers and a shim layer to load them into a proprietary kernel may (depending on a whole host of things) create a derived work, and thus subject to the GPL.

Zach pointed out that he's not a lawyer and that he wasn't making an official response, but VMware's only real defences are likely to be along those lines. I personally think they'll have a hard time convincing a judge of that, but we'll see how it goes.


> 1) There is no argument that depending on a Linux console OS makes any part of ESX subject to GPL that is not already opene sourced.

Yes there is: the GPLv2 says:

"If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."

You would have to not consider the ESX product "a whole which is a work based on" the COS.

Naturally, this interpretation would extend to just about everyone who builds virtual appliances, special-purpose bootable CDs, etc. So it would be an unfortunate interpretation. (In particular, you couldn't intermingle GPLv2 and GPLv3 software on a virtual appliance!) But just because it is unfortunate does not mean it is not valid.

[btw, it's worth noting that the COS basically no longer exists.]


There is already precedent for the separation of software licenses at process boundaries, if the GPL was viral enough to cause issues with virtual appliances then Linux distributions would be in deep water already since they are a product of the combined software included on the installation media.


The FAQ implies the lawsuit is relating to the Linux kernel: http://sfconservancy.org/linux-compliance/vmware-lawsuit-faq...

> This case is specifically regarding a combined work that VMware allegedly created by combining their own code (“vmkernel”) with portions of Linux's code, which was licensed only under GPLv2. As such, this, to our knowledge, marks the first time an enforcement case is exclusively focused on this type of legal question relating to GPL. However, there are so many different ways to make combined and/or derivative works that are covered by GPL that no single case could possibly include all such issues.


I also find it unlikely it's just the name and license number. They used to return all of a driver's information (name, phone, address, drivers license, license plate, etc) from the rest endpoint they were using on their website. They closed that hole it after it we disclosed it to them.


I think most new "netbooks" have been converted into 11.6 form factor to include a proper full sized keyboard. The only real reason netbooks had 10" displays was because intel required it when purchasing an atom (along with their 2gb memory limit). Atoms haven't gotten any real architectural (IPC) changes since their release and Intel has been repositioning the brand/hardware towards tablet/phone devices. Since manufacturers have been freed from the 10" constraint, such most manufacturers have been building larger screened low end laptops which is really what the market wants. As such you might want to reconsider your options. Depending on the architecture of the Celeron, it may actually be faster and more battery efficient than an Atom. The options seem to be:

1/ Deal with an extra inch of real estate

2/ Buy a 7/10" tablet & add a keyboard. Some like the Asus transformer pad includes a keyboard dock. You can also try rooting/chrooting a linux distro onto the tablet all the bells and whistles.

3/ Buy used from e-bay


An extra inch of screen diagonal is great, of course. But it usually means an extra inch of notebook. They should just take the old netbook form factor and build in a screen that goes to the edge (keeping the bezel very thin).

Also, I think vendors used the switch from 10" netbooks to what we have now to raise the price tag unproportionally.

They could probably build something with a touch screen, detachable keyboard, HD video playback, all day battery life, that could run circles around every netbook, and sell it at around $350 (or even cheaper without touchscreen, and with a fixed keyboard). Instead, they slap in a i7 and 8 Gigs of RAM, that most people won't use anyway, and sell it for twice as an "ulrabook", because there's more money in "premium"...


My company uses lastpass to share passwords. Any passwords that is saved to the 'shared accounts' folder is automatically shared to everyone on the team.


It reminds me of http://www.fefe.de/ncp/ It's always interesting when people come up with the same thing independently.


I couldn't seem to get this compiled on OSX :( Do you (or anyone) know if there's a OSX version available? What I like about ncp is that it first requires an action at the sender (push) and then at the receiver afterwards (poll).


Ah yes, I take a slightly different approach, I don't do polling, only have a listener and a single request sent.

Though, this still looks more robust, thanks for the link.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: