Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Wayland bashing (Score 5, Insightful) 151

I've read the codebase. Mostly to discover the grey areas in the protocol when I was working on a X/Window server running on ms-windows. The code is not pretty but that is mostly due to being an old code base.

The X protocol has its problems and quirks too, particularly when dealing with long latency between server and client. It was designed when using high-level primitives (eg "draw line to (x,y) in color Z") made sense. When client just use such primitives the speed is impressive. But some 10 years ago clients started doing client rendering and just sending bitmaps to the display server. Mostly that meant higher bandwidth and fewer round-trips. Whether that is good or bad depends on the clients and the environment.

I have followed the progress of wayland a bit, and I have actually seen some of the presentations. It seems to me that wayland initially was infested by the type of developers that think that all they need is direct access to video memory, and for remote applications all you need is VNC-style full-desktop remote. Of course people who use remote X think that that is a myopic and arrogant view. It seems that wayland has gained some developers in the past few years who have more common sense and one of the new goals is to support remote X clients in a root-less fashion. When they have implemented that and also made sure that both clipboard and X-selection work then I'll give wayland a shot.

Comment We try to make it better (Score 2) 126

We (privavore) are creating a fork for Firefox. (privafox.) By default we change all cookies into session-only. But with twists:
  - persistent cookies are allowed for sites that you provide a password to. The assumption is that if you log into a site the you probably want your shopping cart retained, and that by logging in you realize that the site will keep track of you. But we don't allow 3rd-party cookies.
  - workarounds for the EU cookie consent (in progress). By disallowing cookies by default you will get the "we use cookies to improve your experience" prompt.
  - user-agent is fixed (in-progress). That makes it a lot more difficult to distinguish different users behind the same ip (NAT).
Both firefox' and chrome's private browsing mode leaves something to be desired. But that's ok.Their developers focus on creating the best browser. We just provide "after-market" customizations. Not for you, but for your less tech-savvy parents.

Comment Re:Better summary (Score 1) 133

THAT is the simplest way to access X securely, by running remote code??

It's a one-liner by using SSH to localhost.

The "correct way" is a bit more cumbersome: Use 'xauth' to generate an authorization key with the "untrusted" flag, then tell the untrusted program to use that authorization key with the XAUTHORITY environment variable.

Comment Better summary (Score 5, Informative) 133

"snaps" is a new package format for applications on Ubuntu. It is basically a package with dependencies, bundled together and meant for running in a container (docker or lxc I suppose?) which means that the OS is protected from it.

However, since the application has access to X11 window server it has access to the facilities in it including monitoring keystrokes and mouse gestures sent to other X11 applications. So essentially a "snaps" can be a trojan keylogger.

The article/blog does _not_ explore if X11's "untrusted client" feature would help.

Comment Right to be forgotten - subcases (Score 5, Interesting) 132

I checked a subset of the leaked list from BBC last year of articles they had to remove. From those samples I could see three categories:

1: victims. Eg sexual assault victims mentioned by name. It seems OK to me that they get their name removed so that in 20 years their granchildren don't get that search result.
2: a small category of criminals wanting to have their names removed. Which mostly seems OK to me as most countries have a limit to how long such information is publicly available. Eg. I think where I live burglaries are removed after 8 years
3: a wtf category. Two examples: One neo-nazi wanted his name removed from an article about a white power demonstration.. His names is pretty unique so I checked - he is still sputing such nonsense on facebook and twitter, so I don't see why he wanted it removed. The other example is a man in an article about how his one testicle suddenly grew and he immediately went to the doctor. It turned out it wasn't testicular cancer but a benign internal boil. I think it is a positive story about cancer awareness, but I can see why he may not want that to be the first result when someone searches his name.

So basically I agree with the right to be forgotten. When information is no longer in the public interest it should be possible to get the names removed.

Comment Re:There's no doubt that... (Score 1) 1839

I would like the threading system to not encourage people to reply to the top-most thread. Like I'm doing now.
The first comment could be inane or completely un-insightful yet people are forced to reply in that thread in order to get a chance to be seen.

Perhaps you could just disallow the first comment to be from an AC? That could solve multiple problems.

Comment Re:Echoes my experience (Score 1) 217

At the time when I saw the DUL blacklist problem was when ISDN and plain dail-up was still common for companies (ADSL wasn't widespread yet, and SDSL was generally too expensive). So blocking email because the sender IP was marked as dial-up was pretty stupid.

Comment Re:Echoes my experience (Score 1) 217

Good to know that they still have problems.
Back when I had the problem it was sporadic and I could never recreate the problem my self. I'm tempted to block emails from but unfortunately there is one person with an address there that I have to talk to occasionally.

Comment Echoes my experience (Score 5, Interesting) 217

I've been running my own mailserver since 2003, and I have seen my share of problems.
1: mailservers blocking mail based on spamhaus DUL. You can delist your IP. But still, blocking exclusively on that?
2: accepting emails and then discarding them silently. No trace of them. No bounce. Recipient did not have it in their spam folder or anything. This was several years ago, so perhaps it's better now. But discarding emails after promising to deliver them without any possibility for the recipient to control it: bad idea.
3: Various greylisting email servers. Not really a problem as my MTA will retry and the email is only delayed for a few minutes.
4: rejecting emails sent over IPv6 but happily accepting them over IPv4. It turned out to be a problem with their parsing of SPF records, and apparently fixed now. But I did find out that there is no reasonable way to contact the gmail team.
5: rejects emails due to FBLW15, whatever that means. It seems you can get whitelisted, but it appears that a lot of hosts are being hit by it for no reason.
6: office365 bouncing emails due to "protection" with no explanation given, and direction to contact the recipient by other means to get whitelisted. This was for a the official email address listen on a company website. I decided that my email wasn't important enough. Their loss.

Bottom line: If you run your own email server then expect to occasionally do some manual whitelisting etc. And expect some email servers to be uncooperative and/or RFC-clueless.

Comment Re:Moral of the story: (Score 2) 147

The content plugin support has always been a mixed blessing. It was sometimes useful as a stop-gap until the browsers supported some new form of content (eg. SVG, MathML, ...). With the removal of plugin support and acceleration of the death of plugins it means that new content forms will have to be implemented in all browsers, which seems wasteful to me.

On the other hand, with the current feature set of html5+javascript+canvas+webgl you can make quite good interfaces. In the odd (but not completely rare) cases where it isn't enough you can go for a stand-alone program, like java webstart, stand-alone flash player, etc.

So what we lose is the ability to display new content forms inside a web page which (imho) is not a big loss nowadays.

For the legacy sites (java applets for configuration or secure "VPN" access, flash for ditto) the backward compatibility has never been great: random applets required exactly JVM 1.4.x.x, flash only worked with FF version x, silverlight only worked with IE, etc. so I don't think the impact is worse than what would already happen. I hope that the developers of such solutions go for html5 replacements primarily, and if that doesn't work then downloadable stand-alone binaries (or even better: open source).

Comment Re:Here's how we do it (Score 1) 318

It sounds like you are doing it right. I wish you'd tell your story more places.

Whether remote work is accepted or not does depend on culture. Some of it may be due to the particular country culture. Eg. if the companies in a country generally have deep hierarchies and generally view the employees as peons and the employees in return do as little as possible then remote work is unlikely to be accepted. But while the overall country culture has an impact the company culture has more impact.

My story:
After getting tired commuting to my first job (45 minutes each way), I changed jobs and moved to the city where the new company was. I had 10 minutes walking distance.
Then that company moved offices (IT boom, more employees, etc.) 36km away. I went to my manager and essentially said: remote work or else! It wasn't a problem because he was in the same boat as me (living in the same city). So we settled on two days remote work per week, tuesdays and thursdays as a general rule. I think I was the first employee ever to have regular remote work. It worked so well that gradually more and more employees were allowed to work some days at home. It wasn't a requirement that people worked at home. Some preferred to come in each day (even those with a longer commute) for various reasons (wanting to keep home and work separate, home being a circus with 3 children, ...).
So that worked fairly well for 14 years. In all that time I think there was only one who didn't pull his weight (eventually sacked).

The important things for making it work was:
  - people know that you are working at home. Regular home-working days help.
  - people know how to contact you and being available. I was sometimes praised for answering emails quicker than most people answered skype mesages.
  - general respect and trust among colleagues.
  - technical side must be OK. Internet, email, IM, and occasional conference calls. (*1)

Then after those 14 years this happened: bought by another company which had a mix of US, UK, AU and IN offices. And heavy-handed implementation of that abomination of agile that is SAFe. As per the SAFe instructor home work was impossible because, well, it said so in the book and the superficial guides to SAFe and SCRUM. Never mind that the work-from-home was in my contract and changing that would require the usual notice period. I could see where that was heading, and didn't have the energy handle it, so I quit.

Since then I have been a contractor for primarily a US business. 100% remote work. It is accepted that I'm in a completely different timezone. Occasionally there are conference calls at my local time at eg. 22 in the evening but they are few. I miss having colleagues but the freedom makes it worth it (it may not be for all, though).

Note 1:
On the technical side I have some observations:
  - Decent and stable internet access is a requirement.
  - Remote access must be available. It must be platform-agnostic. Cisco-VPN (binary blob in kernel) doesn't cut it. SSL-VPN is marginally better.
  - Email must work (so if your IT department doesn't know how to make SMTP, IMAP and LDAP work then whack them with a cluebat)
  - Conference calls must use local bridges. There are plenty of companies offering global conference calls and all the ones I have tried are shit. They all compress the sound too much and when someone is calling in via a GSM connection then the double compression has all the usual issues (sounding like being in a barrel, comfort noise, ...)
  - Platform-agnostic IM is a requirement.
  - Platform-agnostic voice/chat client is desirable. No, MS "skype for business" doesn't cut it.

I remember at the start (around 2000) the remote access wasn't available, so I set up a cronjob on my office workstation that checked for emails and made a remote X connection back to my home. The system administrator raised his eyebrows when he one day saw a direct connection to/from the outside. Fun times :-)

Slashdot Top Deals

"Consider a spherical bear, in simple harmonic motion..." -- Professor in the UCB physics department