Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment I would, if.... (Score 1) 151

... if it was easy to un-brick a phone be resetting it to factory settings; I'd be much more eager to do so.

Ideally, in my mind, it'd work just like a PC --- where I could make a backup image of the Factory Disk Image (just in case); and then install whatever I want on it; knowing that it wouldn't be hard to boot from an external device and restore the factory image.

Anyone know of such a phone --- and that'll be the next one I'd buy.

Comment Re:Superior summary enclosed (Score 1) 93

13,584 were accessible .... the remainder is assumed to be nefarious,


At least some of those are probably my "hello world" virtual machines where I set up a hidden services that serve literally just the static page '<html\>Hello World\</html\>', or just the default installs of things like WikiMedia, just to see if i could.

I never could figure out anything interesting to do with them; so they're just hosting empty wikis, blogs, etc; that were locked down so I'm the only one that can get in, to avoid spammers from uploading crap into them.

TL/DR: No, most of the inaccessible sites should not be 'assumed to be nefarious'. Just boring.

Comment ported large cluster from SQL Server to Postgres.. (Score 5, Interesting) 314

TL/DR: About a 5x-10x CPU and Disk I/O improvement migrating a pretty large project from [a major proprietary database mentioned in the article]* see edit below to Postgres. CPU and Disk I/O Graphs below.

Here's one data point - based on from experience migrating a pretty big system from [a major proprietary database mentioned in the article] to Postgres, I think the two biggest advantages Postgres has are:

GIST and GIN indexes (and soon BRIN indexes), and

Writeable CTEs.

We migrated a very busy, pretty large (24 CPU core, 256GB RAM, 20TB disk space) system from [a major proprietary database mentioned in the article] to Postgres about a year ago. These graphs measuring CPU and disk activity provide a nice visualization of the improvement:

Note that with [a major proprietary database mentioned in the article], all 24 CPU cores in the system were over 40% utilized (and growing) 24x7 most days a year. After a pretty naive port (November to May in the graph) the CPU load fell to an average of about 10%, and the disk array's queue length fell from painful to near zero. After adding some Postgres-specific code, we got it down to an average of near 5% (shown in the most recent month in the graph).

CPU differences seem to have been mostly related to the availability of GIN indexes in Postgres, which can be much more efficient on certain types of data (like the OpenStreetMap road network).

Disk I/O improvements seems to be mostly related to Postgres's far more compact storage of XML data. Seems SQL Server stores XML data using 2-bytes-per-character for the data itself; and on top of that adds extremely large indexes. In contrast, the "toast" feature in Postgres means the XML data takes an average of less than one byte per character for the data and its "functional index" feature allowed for far more compact indexes. One of our XML-heavy databases went from over 600GB in SQL Server down to 140GB in Postgres, with more efficient indexes.

For a few months we tried to stay database-agnostic so it'd be easy to port back if we needed to -- but after a while we started adding Postgres specific changes. The benefits of those Postgres specific changes can be seen near the end of those graphs. An enormous improvement occurred when we changed the inserts and updates to use the Writable CTE features following recommendations someone outlined here


In the end, Postgres looks to me like it's saving us like 5X in hardware costs as we continue to grow.

Edit: I'm told this proprietary database vendor dislikes users publishing benchmark results comparing their software to F/OSS databases. I'd argue that this is more of an anecdote than a benchmark; but just in case I edited the comment to remove the vendor and product name from the parts that talk about performance.

Disclaimer: As mentioned in a comment below, we tried to tune each the systems to the best of our team's abilities, but aren't really experts in tuning either database system. No doubt each system's results could be improved by people who were deeply available with each databases internals (which I argue is much easier to find for Postgres, since its mailing lists have thousands of people familiar with the internal code).

Comment Re:speaking as an engineer, it happens. (Score 2) 323

Linus remains the sole gatekeeper for what goes or doesn't go in the kernel

He isn't.

You're free to release your kernel with whatever patches you want to approve or reject just as much as Linus can.

In fact - just about every major distro works that way - applying not necessarily the exact same set of patches that Linus does.

Of course many people trust Linus, so most distros follow him pretty closely.

But that's because people trust him - not that he's some magical "Gatekeeper".

Slashdot Top Deals

Everybody needs a little love sometime; stop hacking and fall in love!