Please create an account to participate in the Slashdot moderation system


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Amazon's New SSL/TLS Implementation In 6,000 Lines of Code 107 107

bmearns writes: Amazon has announced a new library called "s2n," an open source implementation of SSL/TLS, the cryptographic security protocols behind HTTPS, SSH, SFTP, secure SMTP, and many others. Weighing in at about 6k lines of code, it's just a little more than 1% the size of OpenSSL, which is really good news in terms of security auditing and testing. OpenSSL isn't going away, and Amazon has made clear that they will continue to support it. Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions. Further more, it implements a relatively small subset of SSL/TLS features compared to OpenSSL.

Surveillance Court: NSA Can Resume Bulk Surveillance 161 161

An anonymous reader writes: We all celebrated back in May when a federal court ruled the NSA's phone surveillance illegal, and again at the beginning of June, when the Patriot Act expired, ending authorization for that surveillance. Unfortunately, the NY Times now reports on a ruling from the Foreign Intelligence Surveillance Court, which concluded that the NSA may temporarily resume bulk collection of metadata about U.S. citizens's phone calls. From the article: "In a 26-page opinion (PDF) made public on Tuesday, Judge Michael W. Mosman of the surveillance court rejected the challenge by FreedomWorks, which was represented by a former Virginia attorney general, Ken Cuccinelli, a Republican. And Judge Mosman said that the Second Circuit was wrong, too. 'Second Circuit rulings are not binding' on the surveillance court, he wrote, 'and this court respectfully disagrees with that court's analysis, especially in view of the intervening enactment of the U.S.A. Freedom Act.' When the Second Circuit issued its ruling that the program was illegal, it did not issue any injunction ordering the program halted, saying that it would be prudent to see what Congress did as Section 215 neared its June 1 expiration."

Is Safari the New Internet Explorer? 307 307

An anonymous reader writes: Software developer Nolan Lawson says Apple's Safari has taken the place of Microsoft's Internet Explorer as the major browser that lags behind all the others. This comes shortly after the Edge Conference, where major players in web technologies got together to discuss the state of the industry and what's ahead. Lawson says Mozilla, Google, Opera, and Microsoft were all in attendance and willing to talk — but not Apple.

"It's hard to get insight into why Apple is behaving this way. They never send anyone to web conferences, their Surfin' Safari blog is a shadow of its former self, and nobody knows what the next version of Safari will contain until that year's WWDC. In a sense, Apple is like Santa Claus, descending yearly to give us some much-anticipated presents, with no forewarning about which of our wishes he'll grant this year. And frankly, the presents have been getting smaller and smaller lately."

He argues, "At this point, we in the web community need to come to terms with the fact that Safari has become the new IE. Microsoft is repentant these days, Google is pushing the web as far as it can go, and Mozilla is still being Mozilla. Apple is really the one singer in that barbershop quartet hitting all the sour notes, and it's time we start talking about it openly instead of tiptoeing around it like we're going to hurt somebody's feelings."

Quebec Government May Force ISPs To Block Gambling Websites 60 60

New submitter ottawan- writes: In order to drive more customers to their own online gambling website, the Quebec government and Loto-Quebec (the provincial organization in charge of gaming and lotteries) are thinking about forcing the province's ISPs to block all other online gambling websites. The list of websites to be blocked will be maintained by Loto-Quebec, and the government believes that the blocking will increase government revenue by up to $27 million (CAD) per year.

Comment: Re:There are a few options. (Score 1) 210 210

Well, if you want frequent filesystem or directory snapshots rather than per-file per-change versioning then your options are much broader.

LVM can do snapshots besides doing disk pooling, and can do a sort of clustering. Btrfs pools disks and does snapshots without the clustering. XFS has indirect support for snapshots -- it allows one to freeze the filesystem and snapshot using the volume manager. Ceph is a highly available clustered storage system with a POSIX FS face and does snapshots. Lustre allows taking LVM snapshots of its MDT and OST filesystems, although doing so often could be a bottleneck. Gluster (since 3.7 or so) actually wraps around LVM's snapshot tools so long as each "brick" is on a thin LVM that contains no data besides the brick.

ZFS does pooling and snapshots. It's supported-ish on Linux both as a kernel module and as a FUSE filesystem. It has much better support on the BSDs and of course on OpenSolaris/Solaris.

It's notable that the Ceph folks recommend Btrfs underneath Ceph as the local filesystem for development and testing but XFS under it (or optionally ext4) for production at the moment.

Comment: Re:There are a few options. (Score 1) 210 210

Getting the network storage enabled without a single point of failure is easy, especially if using a distributed replicated system. Getting versioning to work without a coordination point for the versioning is a much more difficult problem to solve.

I want to note that while many people voice distrust or even disgust with it, FUSE by itself shouldn't disqualify a solution. Lots of high-performance filesystems get their POSIX FS layer via FUSE.

Also, while versioning and clustering are a different problem the similar issue of frequent snapshots and clustering is well solved. Gluster, MooseFS, CephFS (part of Ceph), and others support snapshotting just fine. No matter how frequently you snapshot, it's not quite the same as versioned files. It is often worth comparing the two, but one is not a true replacement for the other.

Something like git that's designed to allow branching and merging is helpful here, but as has been pointed out using a FUSE-mountable file system like gitfs over a git remote is not the cleanest of solutions either. There are application libraries that handle checking things into and out of git pretty transparently, buy altering applications is definitely not the same as doing something at the FS level. All the clients fetch the changes from the repo, and the repo can be cloned elsewhere for backup or stored on a clustered FS itself or whatever. Since gitfs gives every client all the history, all clients have a record of all the versions. I'm tempted to set gitfs up and test it heavily, but I've only barely poked at it before now so I can't say how sturdy a solution it might turn out to be.

Something like NILFS2 or tux3 handles versions but only knows about the one file system. You gain storage reliability by putting it over something like DRBD to replicate the storage, but it's expecting to be a single master of that FS frontend.

So, yeah, it's easy to get either clustering with no single point of failure or to get file versioning. It's a bit more challenging to combine versioning with no single point of failure for the data storage. It may be a downright difficult problem to get the versioning itself to have no single point of failure.

Putting a distributed parallel FS that uses a local POSIX FS on each node, and then using a versioning file system on those nodes is, as I said in a previous post, not ideal. It makes versions on each of the storage nodes, but then your version browsing and restoration is on each individual node. A client app that connect to one or another backend directly, lets you pick a version to restore, then writes that back through the cluster may be a good enough work around in some environments.

Comment: Re:There are a few options. (Score 1) 210 210

I doubt my life will ever depend on the OP's needs of a versioning distributed filesystem.

If I had to pick some combination out of that which I've seen work well with my own eyes, I'd share NILFS2 over CIFS or NFS, possibly with DRBD underneath LVM underneath the NILFS2. I've never done that exact combination. I have run NILFS2 on top of LVM, and I have run DRBD underneath LVM. I've shared lots of things, including NILFS2 and various other FSes on LVM over CIFS and NFS. I've never done DRBD under LVM with the NILFS2 filesystem on top, though. I wouldn't be scared to recommend testing it, but I wouldn't rush it into production that way.

Comment: There are a few options. (Score 4, Informative) 210 210

Contrary to popular rumors, there are a number of ways to do what you want. I can't vouch for all of these combinations working and wouldn't be too optimistic about tackling some of them. The more advanced stuff can take quite a while to ramp up to speed.

If you don't mind FUSE as an intermediary, there's gitfs that uses git as a file system (which is kind of is anyway, beyond being just a VCS). It creates a new version on every file close. You can point it to a git remote on the same machine or across a network which lives on any filesystem.

You already found that there are some non-mainline kernel modules for filesystems like next3, ext3cow, or tux3 that do versioning on write. NILFS is actually in the kernel these days (since 2.6.something) . More information about NILFS2 shows that it's somewhat slow but that it is in fact a stable, dependable file system.

Subversion has a feature that you can put WebDAV in front of it, mount the WebDAV as a filesystem somewhere, and every write creates a new revision of the file in SVN. That gets you networked and versioned. This works similarly to gitfs but uses WebDAV. You could if you wanted use dav2fs in front of that to treat it like a normal file system again.

You can then share any of these over SMB with Samba. Or you can shared them via NFS.

If you need really high-end, fast, replicated network filesystems you can use any of the clustered storage systems that will use a storage node's underlying files with any of these below that, but that will put your revisions underneath everything else rather than on top. Then there's using something like gitfs with the remote on top of, for example, DRDB, XtreemFS, or Ceph (for example even across CephFS which presents Ceph as a normal POSIX filesystem). This latter option puts your revisions closer to the user and then each revision gets replicated.

I've personally never used some of the more exotic combinations listed here. You could in theory put NILFS2 on LVM with DRBD as the physical layer (since DRBD supports that) and then serve that file system via Samba (CIFS) or NFS which I would expect to work well enough if slowly.

Comment: Re:This will NOT half the cost of batteries (Score 1) 214 214

Obviously you're going to have to have a line connected already to have long distance service on it. Voicemail or caller ID are generally among those "select services" in the US. I would imagine if we spent all day digging through the fine print it's not that big a deal.

Comment: Re:This will NOT half the cost of batteries (Score 1) 214 214

Well, if someone really wants to pay by the minute instead of $10 per month for unlimited to Canada and the US or $37 per month for unlimited calls to almost anywhere in the world it's either because they almost never call outbound long distance or they're not very bright.

I wouldn't consider that plan to be the baseline cost. Most people are going to pick unlimited.

Comment: seagate good drives IMO (Score 1, Informative) 297 297

I have 12 seagate drives in a raid array. I finally had one fail, but it was after 8 years or operation, but I think that was my fault because I moved the server to a new rack and it was offline for about 30 minutes and it failed about 30 days later. Data loss? Zero. Personally I think backblaze is the cause of the seagate drive failures.

Comment: Re:Different types of terms (Score 5, Funny) 175 175

Something other than Node is likely used for the static parts of a site or for caching. Apache or Nginx are likely candidates. There are endless stack names, and they can be as silly as we want and someone could still build something useful on them. LAMP got coined because the stack was so popular together, with the 'P' being /P(erl|HP|ython)/ in many camps. That doesn't mean they'll all catch on as common, popular stacks.

Some people use BAPP -- BSD, Apache, PostgreSQL, Perl/Python/PHP. Some people use specifically FreeBSD: FAPP. Some people use FreeBSD, Apache, Perl, and SQLite...

Here are some other less common web stacks:

MongoDB, ExpressJS, Linux, AngularJS, NodeJS, Groovy, Erlang

Scala, Python, AngularJS, Zope

Clojure, Linux, Oracle DB, WebGL, Nginx

PostgreSQL, io.js, Scala, Solaris, Erlang, D

SQLite, Ubuntu, C, korn shell, io.js, TCL

Lighttpd, io.js, C, Kadmelia

Apache, Mumps, io.js, R, Ingres, Twitter API, Enterprise JavaBeans

"Even if you're on the right track, you'll get run over if you just sit there." -- Will Rogers