Nonsense. They're just ahead of the curve, the same way the porn industry is always ahead of the curve in video technology. (Multiple camera angle DVDs? Yeah, first used in porno...)
it will all become mainstream down the road. You may think it's only of interest to an undesirable fringe of society, but reality is they're the early adopters because they are social pioneers.
You're talking about two very different things. The old Monero (pre-0.9) kept the entire blockchain in RAM and so required huge amounts of RAM to be installed in the machine. The current version uses LMDB which is a memory-mapped database. The mmap may use a huge chunk of *virtual address space* but it never uses more than the currently available amount of RAM.
It is vastly more efficient than the old code. It also vastly more efficient and more reliable than LevelDB, which is used in Bitcoin.
MongoDB uses mmap but the similarity ends there. It uses a journal, not COW. It suffers from a number of durability and consistency vulnerabilities. LMDB has no such weaknesses.
CouchDB is a pure append-only design which means that within a few dozen write operations, 90+% of its space is filled with out-of-date records. It requires frequent periodic compaction phases, and each compaction phase has a significant negative impact on latency and throughput. LMDB requires no compaction, and provides consistent latency and throughput at all times.
They are similar in that both use COW, but the similarity ends there.
Totally agreed. The lack of guarantees re: UDP is built into the UDP spec, it's not a failing of the Linux kernel (nor any other OS) that it won't tell you about dropped packets. Luke, you should know better than this.
with my Atari ST. It was trivial then since the same chip controlled both the keyboard and MIDI ports, just redirect one of the intercept vectors to catch the incoming MIDI packets and feed the notes to the keyboard buffer.
It's more fun to do this with a Zeta MIDI violin. I programmed it to move the mouse pointer on glissandos too, could do pretty much anything without touching keyboard or mouse.
As a related example, I was recently (last summer) confronted by a patchset from [a prominent network router manufacturer] for OpenLDAP, which they wanted to contribute back to the Project. Upon reviewing the patchset, I found they were using an OpenLDAP release from 2001, and this is the code they've been embedding in the firmware of many of their router products from then till now. Many of the patches they sent me were in fact patches I had written for the Project, which they had backported somewhere in the mists of time.
So, thanks to OpenLDAP's permissive license, there's a lot of network hardware out there running ancient, patchwork code that's massively obsolete, along with a crazyquilt of patches of widely varying quality. None of the users of this hardware have any idea of what's inside there, no one can say what security vulnerabilities may or may not exist in any particular model # or serial #, because the code itself is just a frankenstein jumble.
Personally I would have preferred the GPL, because it would have prevented this sort of situation, but it would be quite difficult for the OpenLDAP Foundation to contact all of the copyright holders and ask them to approve a license change, and I suspect a number of them would refuse to change.
Just keep in mind - the freedom that permissive licenses grants to proprietary software companies almost always works to the customers' disadvantage. They will allow their code bases to diverge, they will allow bitrot to set in, they will allow CVEs to go unaddressed, and no one outside will know exactly how bad things are. Until perhaps 10-15 years later, if someone inside the company wakes up and realizes how untenable their situation really is. But the problem is these companies always jump down this path at first; they haven't looked far enough down it to see where it goes.
You would be doing anyone you make such a recommendation to a disservice. BerkeleyDB was a nice piece of work for the 1980s. It is totally outclassed by LMDB today.
5.0 is pretty ancient. MySQL abandoned BDB as a backend in 2006, shortly after Oracle acquired BDB. They couldn't use vanilla BDB, it required their own patches to the BDB source tree.
Yes, it's overblown, but tmpfs is not a reliable solution. If the system is under heavy enough load and memory pressure, the tmpfs contents may get swapped out to disk anyway.
And oh yeah, the swap partition on your disk is a liability too. But anytime someone has physical access to your disk, all bets are off anyway...
I rewrote the pidgin-otr plugin to use plain libpurple a few months ago. It will work on anything that libpurple works on, including finch. You can read about it here
On that topic, i guess it would be a really good idea to write an OTR plugin for the vanilla Android SMS app. Something for my todo list if it hasn't already been done. (PS, you can find my OTR plugin for Finch/libpurple here https://gitorious.org/purple-otr )
Google has been grossly negligent from Day 1. I paid ~ $600 for my G1 phone 2 years ago, and got zilch for customer support from Google, and nobody at T-Mobile was smart enough to even know what to do with any Android technical problems. When people are paying this much real money for a product, by god you better offer them real technical support.
You can't find any dedicated email address or phone number to report issues, the best you can do is file a bug report that's unlikely to be acted on, or post on groups.google.com and hope some bored developer with a few cycles to spare reads your post. That's completely inexcusable for the price people pay for these devices.
I've stuck with it because I've been able to download the source and fix issues I've run into, but only after many days of beating my head against the poorly or non-documented interfaces in the system. But again, regular customers paying real money shouldn't have to do that. For this kind of money, there should be dedicated customer support people who are proficient with the OS and the range of devices, and there should be complete documentation on all of the bundled features.
A lot of students are bad at algebra simply because they don't understand what to do with x and y in e.g "y = 2x", so you still need at least part of the test to force them to work all the way to a concrete result from concrete inputs. Again, there's a big difference between theory and practice, and people should be learning both.
blackbook.com already exists. So does datebook.com, playbook.com, and probably anything else you can think up. Since Facebook's trademark scope is so broad, I'd guess all those other guys will be in their sights soon too.
Or just create your own work, no need to go fishing for something from the public domain.
I've recorded several music CDs in my various bands thru the years. I could go find the current favorite CD DRM scheme, ask for it to be used on my next run of CDs, and go to town. But I guess DVDs are more interesting these days.
Hi-Def camcorders are getting pretty cheap now. Go make a home movie, master it in BluRay format, and have some small-run disc printing house produce it for you. Bingo.
Slashdot Mirror
Ah the good old days of XDAndroid. Fun times...
They might have what it takes, but particularly in the US, their abilities were not trained up and refined.
https://www.cs.utexas.edu/user...
Nonsense. They're just ahead of the curve, the same way the porn industry is always ahead of the curve in video technology. (Multiple camera angle DVDs? Yeah, first used in porno...)
it will all become mainstream down the road. You may think it's only of interest to an undesirable fringe of society, but reality is they're the early adopters because they are social pioneers.
Read the cryptonote.org whitepaper, this *is* a solved problem.
You're talking about two very different things. The old Monero (pre-0.9) kept the entire blockchain in RAM and so required huge amounts of RAM to be installed in the machine. The current version uses LMDB which is a memory-mapped database. The mmap may use a huge chunk of *virtual address space* but it never uses more than the currently available amount of RAM.
It is vastly more efficient than the old code. It also vastly more efficient and more reliable than LevelDB, which is used in Bitcoin.
The Deep Space Network has been transmitting 2.5 bits per photon for the past 30+ years. http://what-when-how.com/space...
How do these researchers not know that already?
A couple new answers to that question have popped up in the intervening time.
https://www.usenix.org/confere...
https://www.usenix.org/confere...
MongoDB uses mmap but the similarity ends there. It uses a journal, not COW. It suffers from a number of durability and consistency vulnerabilities. LMDB has no such weaknesses.
http://www.slideshare.net/mong...
This research group at University of Wisconsin cites 1 vulnerability for LMDB, but they were mistaken:
https://www.usenix.org/confere...
http://www.openldap.org/lists/...
CouchDB is a pure append-only design which means that within a few dozen write operations, 90+% of its space is filled with out-of-date records. It requires frequent periodic compaction phases, and each compaction phase has a significant negative impact on latency and throughput. LMDB requires no compaction, and provides consistent latency and throughput at all times.
They are similar in that both use COW, but the similarity ends there.
Totally agreed. The lack of guarantees re: UDP is built into the UDP spec, it's not a failing of the Linux kernel (nor any other OS) that it won't tell you about dropped packets. Luke, you should know better than this.
with my Atari ST. It was trivial then since the same chip controlled both the keyboard and MIDI ports, just redirect one of the intercept vectors to catch the incoming MIDI packets and feed the notes to the keyboard buffer.
It's more fun to do this with a Zeta MIDI violin. I programmed it to move the mouse pointer on glissandos too, could do pretty much anything without touching keyboard or mouse.
You really need to read ITS#5361 as well.
http://www.openldap.org/its/in...
As a related example, I was recently (last summer) confronted by a patchset from [a prominent network router manufacturer] for OpenLDAP, which they wanted to contribute back to the Project. Upon reviewing the patchset, I found they were using an OpenLDAP release from 2001, and this is the code they've been embedding in the firmware of many of their router products from then till now. Many of the patches they sent me were in fact patches I had written for the Project, which they had backported somewhere in the mists of time.
So, thanks to OpenLDAP's permissive license, there's a lot of network hardware out there running ancient, patchwork code that's massively obsolete, along with a crazyquilt of patches of widely varying quality. None of the users of this hardware have any idea of what's inside there, no one can say what security vulnerabilities may or may not exist in any particular model # or serial #, because the code itself is just a frankenstein jumble.
Personally I would have preferred the GPL, because it would have prevented this sort of situation, but it would be quite difficult for the OpenLDAP Foundation to contact all of the copyright holders and ask them to approve a license change, and I suspect a number of them would refuse to change.
Just keep in mind - the freedom that permissive licenses grants to proprietary software companies almost always works to the customers' disadvantage. They will allow their code bases to diverge, they will allow bitrot to set in, they will allow CVEs to go unaddressed, and no one outside will know exactly how bad things are. Until perhaps 10-15 years later, if someone inside the company wakes up and realizes how untenable their situation really is. But the problem is these companies always jump down this path at first; they haven't looked far enough down it to see where it goes.
You would be doing anyone you make such a recommendation to a disservice. BerkeleyDB was a nice piece of work for the 1980s. It is totally outclassed by LMDB today.
5.0 is pretty ancient. MySQL abandoned BDB as a backend in 2006, shortly after Oracle acquired BDB. They couldn't use vanilla BDB, it required their own patches to the BDB source tree.
http://archive09.linux.com/articles/56835
Yes, it's overblown, but tmpfs is not a reliable solution. If the system is under heavy enough load and memory pressure, the tmpfs contents may get swapped out to disk anyway.
And oh yeah, the swap partition on your disk is a liability too. But anytime someone has physical access to your disk, all bets are off anyway...
I rewrote the pidgin-otr plugin to use plain libpurple a few months ago. It will work on anything that libpurple works on, including finch. You can read about it here
http://lists.cypherpunks.ca/pipermail/otr-dev/2011-December/001226.html
and grab the code here
https://gitorious.org/purple-otr#more
There's already a package for it in Arch Linux.
http://aur.archlinux.org/packages.php?ID=55511
On that topic, i guess it would be a really good idea to write an OTR plugin for the vanilla Android SMS app. Something for my todo list if it hasn't already been done. (PS, you can find my OTR plugin for Finch/libpurple here https://gitorious.org/purple-otr )
Google has been grossly negligent from Day 1. I paid ~ $600 for my G1 phone 2 years ago, and got zilch for customer support from Google, and nobody at T-Mobile was smart enough to even know what to do with any Android technical problems. When people are paying this much real money for a product, by god you better offer them real technical support.
You can't find any dedicated email address or phone number to report issues, the best you can do is file a bug report that's unlikely to be acted on, or post on groups.google.com and hope some bored developer with a few cycles to spare reads your post. That's completely inexcusable for the price people pay for these devices.
I've stuck with it because I've been able to download the source and fix issues I've run into, but only after many days of beating my head against the poorly or non-documented interfaces in the system. But again, regular customers paying real money shouldn't have to do that. For this kind of money, there should be dedicated customer support people who are proficient with the OS and the range of devices, and there should be complete documentation on all of the bundled features.
They claim the battery construction is completely safe, and that the battery keeps operating even after having a bullet fired through it.
http://www.dbm-energy.com/index.php?ms=KolibriAkkuUnterBeschuss
(I'll leave it to you to run it thru google translate if needed...)
My compiler will allow you to write whatever code you want, but it will refuse to compile it into insecure code.
My compiler's source:
main(){exit(1);}
A lot of students are bad at algebra simply because they don't understand what to do with x and y in e.g "y = 2x", so you still need at least part of the test to force them to work all the way to a concrete result from concrete inputs. Again, there's a big difference between theory and practice, and people should be learning both.
blackbook.com already exists. So does datebook.com, playbook.com, and probably anything else you can think up. Since Facebook's trademark scope is so broad, I'd guess all those other guys will be in their sights soon too.
According to this link
http://www.pacificdisc.com/PricingBluRay.html
all BluRay discs are required to have AACS. I also downloaded the license agreement from that page, it's 159 pages long. Not a trivial undertaking...
Or just create your own work, no need to go fishing for something from the public domain.
I've recorded several music CDs in my various bands thru the years. I could go find the current favorite CD DRM scheme, ask for it to be used on my next run of CDs, and go to town. But I guess DVDs are more interesting these days.
Hi-Def camcorders are getting pretty cheap now. Go make a home movie, master it in BluRay format, and have some small-run disc printing house produce it for you. Bingo.