hyuen

shameless plug https://www.meta.ai/?icebreaker=imagine

I won't even take a look at the numbers unless they show a PyTorch model running on it, the problem is the big disconnect between HW and SW, realistically, have you ever seen any off-the shelf model running on something other than NVidia?

First rule of network programming: conservative sending, liberal receiving

The main problem here is that autovacuum threshold is something like c + m * nrows, and in large configurations you could have all sorts of table sizes.

How much change is a lot? 1% of the table + 50 rows (for small tables)? I would argue that sometimes is better to use a fixed threshold, e.g. c = 1000, m=0

All these approaches are hit or miss and are different per configuration. What I found useful is to choose the best parameters you can think of without forcing autovacuum to run everytime, and have an external job run vacuum manually to cleanup whatever got missed... eventually you can figure out the right configuration.

hey, what camera settings did you use for those pictures? they are amazing

you need to install the firmware from intel www.i0.org, I did that and at least my sleeping problems reduced

I think you should take a look at nimble, especially at the slide for exchange efficiency, it is on a microsoft page btw. Disclaimer I wrote the plugin to backup exchange at nimble.

San Jose: software engineers, storage experience a plus

Nimble Storage, the fastest-growing storage start-up in history. Located in San Jose, CA, Nimble has developed breakthrough architecture that combines flash memory with high-capacity disk to converge storage, backup, and disaster recovery for the first time.

Nimble was founded by storage industry veterans from NetApp and Data Domain, and is funded by Sequoia Capital, Accel Partners, and Lightspeed Ventures, three of the most successful and respected venture capital firms in Silicon Valley.

I wonder what kind of stuff can be done with 1Tb of SSDs, much cheaper than RAM, but also somewhat slower...

While SSDs are wonderful for random reads, writes are still very expensive due to their large erase blocks. In a small write (typical OLTP workload), the entire block has to be rewritten --typically 128kB-- even if the modified data is much smaller. That's why it is very important to make the application aware of this fact, or use a log-structured filesystem on top of it.

I believe that for most web applications the ratio is 80% reads, 20% writes, that's why no one has noticed this behavior.

Another even more concerning issue is the wear-out, SSD cells can't take more than ~10000 rewrites. While there is firmware taking care of invalidating those blocks, eventually we can expect data loss if not backed up properly.

I think SSDs are great, as long as we understand their limits... For my laptop I have one and I love it, but I would be seriously doubtful about the safety of my information in some database using purely SSDs.

This is a perfect example of what can you do with RAM that is one order of magnitude bigger than what you can normally afford in regular computers.

It would be interesting to see if the effort that is spent writing programs to load stuff from disk and avoiding seeks gets redirected to solve other problems.

make a torrent

I had a similar experience with an AirNas, which is basically an enclosure for a hard drive that exports a samba share. Performancewise, disappointing, all I could transfer was around 2Mb/s, convenience, maybe, streaming mp3's is fine, but there is no way you can stream movies from it. Noise wise, I think I wasn't as unfortunate as the author of the post, but you have to keep in mind that these systems are more suited for data centers, maybe the Drobo is just a poor implementation of a NAS box. If I were to get a NAS, I would probably look for something that does block storage, such as iSCSI or FCoE, not sure if there are home appliances for that, but with that you can ignore annoyances like unsupported character sets for filenames and similar stuff.

limewire, napster, kazzaa, gnutella, all those things that will be gloriously remembered in the history books :)

They weren't that great anyways, you had to pay for listening after the first time. This is fine with me, but think about all the teenagers out there, I am sure they have found other ways to access music given their practically zero income. Once I talked to my 14 year old niece, and she told me none of her friends use limewire or similars, they use myspace and youtube downloaders. I think that the effort from Apple to shut down paid competitors may not be the solution to their root cause...

hey, checkout lizten.in, slightly different in its conception, but could be a good alternative

I have tried to use hadoop at lizten.in, but it seems overkill specially for small deployments like the basic slicehost option. I tried memcached and sure, it is a good fix for some page rendering issues, but for elements that you want to cache forever (or a relatively long time), I prefer to create a blob table in mysql and store the entries as if it was a key/value pair. I am sure there are more sophisticated persistent datastores, but I guess the idea is the same. Maybe with some high performance storage, such as SSD's and something like berkeleydb it would be feasible to keep a relatively big cache.

could the reduction of this parameter lead to DOS attacks on machines that are not tuned/monitored continuously?

I am looking for something for analytics, I am interested in column storage specifically on something that supports compression. At this point I guess data can fit in one machine, so clustering would be desirable, but not mandatory.

I was thinking about the IOPS that you can sustain with this type of device, and as mentioned here, this is intended for backup, which may or may not be very good acting as a filer.

Probably you can get some high IOPS with all these drives in parallel, but probably not as much as the other more expensive ones (EMC, Netapp).

But I have to agree this is an awesome setup optimized for a specific application. Way to go