View on GitHub

Quorten Blog 1

First blog for all Quorten's blog-like writings

Oh my. Perl poems, sounds like a Haiku. Construct poetry out of tech words, two meanings in one work.

  • RabbitMQ
  • Ruby
  • Ruby on Rails
  • Sneakers
  • Docker
  • Jenkins
  • Vagrant
  • Sentry
  • Celery
  • Raven
  • Ansible
  • Puppet
  • Git
  • Agile
  • Bash
  • Eclipse
  • Python
  • Perl
  • prince

Using `virtualenv`

2016-03-31

Categories: python  
Tags: python  

Using vitualenv:

20160331/https://virtualenv.pypa.io/en/latest/userguide.html#usage

bash
source bin/activate
pip install pylint requests

Or alternatively:

source bin/activate.csh

Serial numbers, as assigned by a central authority. That’s the crux of the problem. They require a central authority. But that’s also the reason for the simplicity. Whereas decentralized number assignment, there is always risk for collision.

I reiterate. The cost of RFID chips. The advantage is that they can be read at a distance, even those without batteries. Thus, roaming device’s locations can be detected very quickly. The disadvantage is that they are more expensive than optical barcodes. Only optical object recognition can track objects at a distance, but again, this requires more sophisticated computer technology, both hardware and software. Again, as has already been the case in the discussion of cellphones, without advanced technology, the only way to be able to locate objects efficiently is to keep consistent home locations. If an object’s location keeps changing, you’ve got to keep making database updates at a high frequency. And, as I’ve indicated early, you’ve got to pay the price for speed, and speed is only possible using newer technologies.

Just to reiterate the point, to be clear. One of the main problems with RFIDs is that they have to include a certain amount of metal, and metal still is expensive. Thus, RFIDs will very likely be “more expensive” for a long time into the future. Maybe advancements in organic electronics will drop the cost of RFIDs, but for now, we know that RFIDs are simply more expensive than other solutions.

No, really, really, what Debian versions and releases do Ubuntu packages come from? I have to know this because all Trisquel packages come from Ubuntu. Basically, all Ubuntu packages are continuously pulled from Debian unstable, regardless of the Debian release version, then Ubuntu-specific modifications are merged in. Oh, wow, that would certainly explain why GNUStep worked so poorly in my version of Trisquel. It actually came from Debian unstable, so it wasn’t even supposed to be working correctly. Yet, Ubuntu indiscriminately merging in Debian unstable, followed by Trisquel cloning Ubuntu, has brought this problem upon me that I have no idea what degree of quality the packages in the Trisquel package repository are of.

20160326/https://en.wikipedia.org/wiki/Ubuntu_%28operating_system%29

Well, anyways, I better get working on that super-meta-distribution system where I can grab packages from all GNU/Linux and *BSD distributions, then store them based only off of their differences, and reproduce the exact original source packages. What about binary packages? That will be a tough one. I’ll try to do some reproducible binary package from source system where I do a compile then a patch apply to mitigate the differences, or I might customize everything completely to try to share unlinked object files across distributions when possible, then link to create the final binaries. Yeah, the point here is, things will be tough. Things will be tough when I have to work with very many different distributions simultaneously.

Take this? Raspberry Pi Zero? Well, actually, not quite. It really depends on what you want to do with your computer. If you need all those manufactured fancies of modern computers, sure, go with the upgraded models. But, if all you need is the pins on the edge to wire up to other things, a Raspberry Pi Zero will save you money.

20160302/http://betanews.com/2015/12/17/the-5-dollar-raspberry-pi-zero-is-too-damn-expensive/

Again, I reiterate. Things that can seem rather random to humans are actually quite predictable to computers. So, just because something seems random to you doesn’t mean that a computer will view that same data as random upon further analysis. Lesson learned, be careful in how you generate the random suffixes for the object identifications. Don’t just use any computer random number generator. Opt to use a cryptographically secure one to generate these random suffixes.

Again, I reiterate, the problem with using local “centrally managed” identification numbers. If the identification numbers are not in a public database, you’ll need office hours access from personnel working in the central database to access any metadata, such as finding the owner’s contact information of a lost pet to return the pet to.

How about attach a USB stick to the dog collar? “Additional information inside.” One problem. People nowadays who have smartphones will have no way of reading the information inside of the USB stick. Okay, how about a Raspberry Pi Zero instead? Okay, that might be a little bit better, but… again, there may still be technical difficulties. How about on the Internet? Again, the problem is how will they know what site to go to? What if you’re using a UUID? The site to go to is subject to change? Indirection? Still, how are they ever going to find things? Look, the problem is that their simply just are no consistent standards in computer technology to build additional applications off of that demand consistency, sorry. But for intermittent applications that only need to work in the near term, such as marketing, then the current semi-broken state-of-the-art is good enough.