I don’t think most people appreciate how big of a deal self-driving cars will be when it is commercially available. When I talk about self-driving I mean fully autonomous car without any driver assistance, not driver assists system like “AutoPilot” in Tesla cars.

Other than Machine Learning, which self-driving cars heavily depends on, no other technology is getting nearly as much funding and attention as the Autonomous car is at the moment. Apart from all the major car manufacturers and ride-sharing services, there are at least a few dozen more independent startups and heavy-hitting tech giants who are making massive investment and bets on self-driving car technology at the moment. Including Google (with Waymo), Apple, Tesla, Uber, some of this companies have no business in car manufacturing or taxi services, yet they are heavily investing and betting on this technology to go mainstream, and want to be the first in the market with the best possible technology and planning to show for it.

Out of all the companies investing in this field, Waymo – a subsidiary of Google – is far ahead of rest in terms of the maturity of their technology, performance on the field and business planning. And to prove their readiness they are expected to go live with their services by the end of this year. Although their service will be available in a relatively small geo-fenced area in a smallish town, it’s still a lot more than anything any other company was able to do.

Having said that, there are real technical and legislative hurdles to overcome with self-driving cars. On the legislative side of things, government moves slowly with laws – because of the disruptive nature of the technology, other companies – who make money through ride sharing or taxi services (trucking services) and likely to lose big time. We are talking about 100s of billions of dollars worth of industry that could affect millions of jobs. So there will be pushback from those industries when it comes to legislation.

On the technical side of things. Waymo is currently way ahead of anyone else in terms of maturity and testing of their hardware and software. Afterall they were working on self-driving technology for almost a decade. Waymo – thanks for google – has their own special purpose machine learning hardware (TPU Chip) which is faster than anything out there. They also build their own in-house LiDAR and radar system and they arguably have the best machine learning software out there that takes input from all this special purpose hardware and convert them into on the fly and make fast decisions for self-driving to be successful. While other very capable people are also working in this field, very few have got everything to mesh together and deliver the expected result as well as Waymo has so far. Before starting their taxi service in Arizona later this year, they have been closely working with law enforcement officials and fire departments to work on ways to handle accidents or incidents involving a self-driving car, they are also working with local government officials to find best ways to start running their service with least amount of disruption. They also have a team of on-call customer service you can call from within the car and they are also training people to service/clean cars when needed. Waymo is approaching this from the top down, not as a half-baked solution. Which waymo puts ahead of almost everyone else in the self-driving race.

Can Self Driving be profitable?

Other than obvious fact that you are removing the human from the equation, there are many reasons to consider why self-driving will be an extremely profitable business which is why so many companies are gunning for it.

Putting all this together, apart from the novelty, there is a real benefit and high-profit potential with autonomous cars and whoever captures the market first is likely to make disruption in the market and making a profit at scale.

I, for one, welcome our autonomous car overloads to take over the roads in the near future.

The post Self-Driving Cars Will Be a Game Changer appeared first on Slashgeek.

Most these involves hardware accelaration involving Intel QuickSync, OpenCL, VAAPI MJPEG, AMD AMF, VideoToolbox HEVC. Even though I have not gotten around running benchmarks, the few encoding tests I have done using Intel QuickSync and NVIDIA NVDEC, the speed bump is noticably much higher without any doubt. Chances are high your linux distro don’t have FFmpeg 4.0 available yet, but you always download binaries for you OS of choice from here: http://ffmpeg.org/download.html

~/Desktop: ffmpeg -i
ffmpeg version 4.0 Copyright (c) 2000-2018 the FFmpeg developers
  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/4.0 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-gpl --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-opencl --enable-videotoolbox --disable-lzma
  libavutil      56. 14.100 / 56. 14.100
  libavcodec     58. 18.100 / 58. 18.100
  libavformat    58. 12.100 / 58. 12.100
  libavdevice    58.  3.100 / 58.  3.100
  libavfilter     7. 16.100 /  7. 16.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  1.100 /  5.  1.100
  libswresample   3.  1.100 /  3.  1.100
  libpostproc    55.  1.100 / 55.  1.100

The post FFmpeg 4.0 “Wu” is here appeared first on Slashgeek.

In Linux (Ubuntu), you can install SSHFS using apt-get install sshfs.
In OSX, you can install SSHFS using brew cask install osxfuse and then brew install sshfs.

The step to mount remote drive itself is very easy: sshfs username@hostname: -ovolname=
You can also make this mount persistent across reboot by making a mount entry on your /etc/fstab/ like this: :/home/users /root/sshfs fuse defaults 0 0

Now you should be able to browse your remote drive using your local file browser.

The post How To Mount Remote File Systems Over SSH appeared first on Slashgeek.

1. unset HISTFILE This will prevent all commands run in the current login session from getting saved to the .bash_history file when you logout. This will reset all commands you ran earlier in session until you logout. There is also no way to verify if it’s working, as you can still use UP key to go to your previous commands. The only way to verify is to logout and login back and check your bash history.
2. Perhaps the best solution, if you want to selectively ignore specific bach commands being logged into bash_history is to type a space before a command. This should be on by default and work on all bash sessions but ff it does’nt work, add the line export HISTCONTROL=ignoreboth to your .bashrc file. In your future sessions commands with space will not be logged.
3. Perhaps the easiest is to type sh and it will start a subshell. Any commands typed in the subshell, won’t be logged into your history, untill you exit from the subshell. Anyone checking your bash history file will only be able to see that you ran sh, but not see what you ran after that.

There are several other clever ways to achieve this but the above mentioned tips are the most common ways of doing this.

The post How To Hide Your Bash Command History appeared first on Slashgeek.

Not all hell is made of fire, some are made of an abyss with no way of pulling yourself out of it. With Social media’s it’s like jumping from one abyss to another. There is a common internet trope, the idea that if you are self-aware enough to understand the dangers of social media you should be able to know when to stop and it should be fairly easy to do so. I am sure it is true for some people, but I can’t imagine it is true for most people.

The Dangers of Social Media:

Social media sites pose more than one form of danger, it’s not always easy to identify the scope, intention or the scale of the dangers. Let’s start with the obvious ones:

• Privacy: This is a big one which should be very obvious to most people who understand what’s at stake (sans the tech-illiterates who are the vast majority of social media users). If the recent Facebook Privacy concerns incident is any proof – despite some people deleting their Facebook account – It still accounts for a very small amount of total Facebook users. This is not the first time there was a lot of noise about Facebook privacy concerns, the last a lot of people deleted their account (small in context) and then everyone forgot about it in few months. Diaspora*, a decentralized, privacy concern facebook alternative, was the result of the privacy concern. But nothing really substantial happened. Facebook user base and revenue increased more than ever.
• Collusion with government: I know at least of 3 occasions, that doesn’t have any public record, that I am aware of, where Facebook has worked with local government to give information about specific Facebook users who were critical of the local government. Despite what Facebook tells you they have a local presence in countries with large Facebook users – and they work directly with the government and follow the local laws, regardless how immoral and unethical they are. It is important to note that Google also does that same thing. Both Google and Facebook were blocked in recent months in my country when they were slow in sharing information, but promptly opened it back up, when I believe they complied with the local government. I don’t know how often this happens, but I know that this happens often enough for it to be a concern.
• Targetted advertising: Social media gives you free access to their platform in exchange for your personal information. Though they never actually say it in writing or in person, this is very much implied. If something is free you are the product. The reason why Google considers Facebook as a real threat to their existence is that Facebook, because of how their platform works, knows more about you than any other social media sites in the world. Not only that – you give this information free to Facebook. The more targeted information Facebook has about you, the more valuable you are to Facebook as a user. I have seen an advertisement on facebook about something in my personal life that I have never shared with Facebook or any platform that I know of, I have seen ads about it on my facebook wall. If this doesn’t scare you I don’t know what should.
• Social media Echo Chamber: We are comfortable with environment and ideas that we are familiar with and with people who agree with the same ideology. Almost all social media that I know of, works on this simple idea, where you usually get to interact with people with similar ideology. This is not limited to Facebook, Twitter, Instagram, Reddit and other lesser-known sites. You are more likely to stick around if your ideology is vindicated by people with similar ideology. Most people don’t like to be challenged. More recently Facebook, Google, and Twitter are employing dark UX design for the sole purpose of you sticking around within their echo chamber. The difference between Apple walled garden and the Facebook echo chamber is that with a walled garden you don’t really have a choice, with echo chamber you are lulled into staying around for the familiarity. Perhaps the most disconcerting is how 100s of millions of people are starting their internet journey through social media like Facebook. Thanks to one of my cousin, every single member of our family who is older but not to internet savvy got their introduction to the internet in the form of apps on their phone and Facebook is their gateway to the internet. Not only are they glued to Facebook more than I have ever done in my life, but they take everything they read on Facebook at face value. I often try to help them do critical thinking and questions things they read on facebook. So far it has been mostly a losing battle. Now that you can easily read articles on facebook without ever leaving Facebook. It has become harder for me to try to weed them out of Facebook.

What about those of us who understand the pitfalls of social media? I can speak for myself and I can tell you that it has not been easy. No, I have not deleted my facebook account or twitter account. As a matter of fact, this website has it’s own facebook page and twitter account. It is very difficult to keep in touch with your family who doesn’t live in the same country or in the same city. I will log in once or twice a month – to get the gist of whats going on with their lives and they all have my phone number and they are welcome to call me when they want. WordPress makes auto posts to twitter and facebook so I don’t have to log in to make those posts on my social media pages.

If it is hard for someone like me, who is self-aware of the pitfalls of social media, I can’t imagine who hard it might be for people who don’t. And for social media sites, those are the actual eye-ball they really want for their advertisers.

The post The Social Media Echo Chamber Hell appeared first on Slashgeek.

As a gif fanatic, I am glad that more people are starting to use WebM more often.

Why ffmpeg?

You can probably use GUI based converters to convert your format of choice to WebM. But chances are high that almost all of this software use a wrapper around FFmpeg to accomplish this anyways. So why not get rid of the middleman?

First make sure that your FFmpeg is compiled with support for libvpx and libvorbis or if you are compiling from source, use this flags:

--with-fdk-aac --with-ffplay --with-freetype --with-frei0r --with-libass --with-libvo-aacenc --with-libvorbis --with-libvpx --with-opencore-amr --with-openjpeg --with-opus --with-rtmpdump --with-speex --with-theora --with-tools

Now you should be able to compile your mp4/fig file using ffmpeg like this: ffmpeg -i 1.mp4 -vcodec libvpx -acodec libvorbis "1.webm".

On my 10+ tests, I have found WebM format to have 1/3th the size of mp4.

The post Converting Mp4 to WebM using FFmpeg appeared first on Slashgeek.

I tend to keep my desktop organized with a folder by projects, for easier access – like a poor man’s mind map. But when I don’t need those folders, they can be very distracting visual noise, it better to hide them.

Thankfully in OSX (my main work computer OS), this can be easily achieved with CLI command, the command itself is not very user-friendly:

To hide Desktop icons:

defaults write com.apple.finder CreateDesktop false; killall Finder

To unhide Desktop icons:

defaults write com.apple.finder CreateDesktop True; killall Finder

But you can make this easier by creating an alias by editing like thisnano ~/.bash_profile and adding you alias:

alias hide="defaults write com.apple.finder CreateDesktop false; killall Finder"
alias unhide="defaults write com.apple.finder CreateDesktop True; killall Finder"

So next time all you have to do it type hide to hide your desktop icons or unhide to unhide show your desktop icons.

The post Hide MacOS Desktop icons using CLI appeared first on Slashgeek.

ALPN (Application-Layer Protocol Negotiation) is a TLS extension that allows an efficient way to negotiate encrypted traffic between the browser and the server. In order to enable ALPN on a server, a web server needs to have HTTPS configured and support the HTTP/2 protocol. ALPN doesn’t provide any additional security benefit over HTTPS, it allows a browser to take advantage of speed benefit of HTTP/2 by lowering the initial handshake latency. As a result, providing faster browsing experience. Considering most major browser already supports ALPN, The benefits of ALPN should be apparent as soon as ALPN is enabled on the server.

If you check you cite using this keycdn tool, you can if your site support APLN or not. The most likely reason your nginx doesn’t support ALPN because you are using an older version of nginx server, even if the version that comes with your distribution is the latest stable version for your distribution, it might not be the latest stable version nginx version available. One way would be to install latest stable nginx from source using OpenSSL 1.0.2 or above, which means you will also need to install OpenSSL 1.0.2 or above from source and them, as shown here. That’s a hard way to do it because chances are very high that you will stumble through dependencies issues when trying to compile from source. The easier and the preferable option would be to installing through this PPA, which has the latest NGINX Stable packages compiled against OpenSSL 1.0.2 for HTTP/2 support with ALPN. Of course, it goes without saying that it’s not a good idea to install packages from untrusted PPAs, and you should only install PPA packages from a source you trust and is linked with the original project.

The post How to enable ALPN on NGINX appeared first on Slashgeek.

According to Google, the whole point of AMP is for mobile users to have fast access to websites without users having to worry about large data usage or load time. There is also issues with websites having pop-up ads, too many external/internal javascript loading, which causes websites to become slow and run background process even after initial loading. AMP prevents this by limiting the amount of CSS/js codes you can use and AMP markups are a small version of the standard HTML/CSS/js code, so in essence, there are not many things you can do with an AMP site – which is why it’s fast.

The problem is you can already make websites extremely fast without having to resort to yet another markup scheme for mobile users. Most sites (including this site) are extremely fast thanks to HTTPS / HTTP2 / Server push / CDN / minifications / browser cache/ compression / and so many other tricks out there. A lot of these were result of active push from Google themselves – more specifically HTTPS is being aggressively pushed by both chrome and firefox and others browsers with visual queues on browser address bar and I don’t think it will be long before non-https sites might eventually get blocked by most browsers (still might take some time), HTTP2 is an evolved version of SPDY protocol made and championed by Google, HTTP2 is only possible if your site already has HTTPS. CDNs are now more or less a commodity thanks to Cloudflare, not too long ago CDN used to be a big deal, it’s mainstream now.

Google also pushed the issue of speed by making search ranking algorithm take site speed as an important consideration (among other things), so it was only natural for a site which depends badly on google search results to feel pressured to implement features like HTTPS, HTTP2. Google has very powerful influence over the web to reshape technology indirectly. Most of the time, it’s for good reasons.

But AMP is not that same, I have tried turning on AMP using WordPress AMP plugin and I have tested both non-amp and amped site and the difference in speed are few milliseconds, not to mention it broke a lot of visual layout of the site – which will require me to do extra work to get it fixed. So naturally, it would make little sense for me to implement AMP on my site – but Google seems to promote sites with AMP on search results – which puts an incentive – however unnecessary it is for me to implement AMP and fix those rendering issues.

Most people (rightfully) thinks AMP is a result of Facebook implementing a similar product. To me, both facebook’s implementation and Google’s AMP feels like such a huge step backward – as if we are back to the walled garden of AOL days. Naturally, I am not too excited about this – but chances are high that I will end up implementing AMP on this. I write this blog because I want users to read my blog – but if google seriously pushes against non-amped sites on their search result – I won’t have a lot of option but to implement it. Probably much sooner than later. Hopefully, on my next attempt with AMP, I will have a better experience.

The post Why I am not too enthusiastic about AMP appeared first on Slashgeek.

If you are running a Web App and you are storing user passwords, it is very easy to get things horribly wrong, it’s better to use third-party sign-in services like Facebook, Twitter or Google. In my experience, I have seen a lot of Web-Apps and Services going this route, not because they are lazy – but because they are offloading an aspect of your app that is incredibly difficult to get it right and secure. In today’s world of high-profile hacking of user password, it’s probably the best thing you can do for your users. Even large companies with well-funded security teams often get things horribly wrong.

But let’s say your app has become incredibly popular, with 1000s of signups per day. There is a point in your business where your user base is large enough for you to start feeling uncomfortable at becoming reliant on third-party sign-in services. At that point, assuming you have the know-how and resources to implement a proper and secure user password storage system, it’s probably not a bad idea to move to your own self-hosted system.

Because it is easy to get things wrong and how often we make this elementary mistakes in the wild, I am going to list three ways NOT to store password.

1. Don’t store user passwords.

The most basic password storage system is to just implement backend database where username and passwords are stored in plaintext. I am not kidding, this is done so often and it is still so common on the web its not even funny. Even today, in the year 2018, you see websites storing passwords in plaintext – you can verify this when trying to recover your password by email, they simply email back your password in plaintext. It’s a huge red flag if you see any websites doing this – stop using their service as soon as possible, or if you must use their service, make sure you are using a unique password. Chances are high that your password is as bad as gone. Because if any website is lazy enough to save your password like this, who knows what other unholy things they are doing security-wise. I once found out my bank was storing the password in plaintext, needless to say, I closed my online banking account. I only used checks or debit-card. You have no business storing your user password in your database.

2. Don’t encrypt user passwords.

The obvious next step would be to implement some kind of encryption when storing a password in the database, better than the previous method, but still, a very bad way to store user password.

This rudimentary encryption process works like this, you take user password, and you use a key to encrypt it and store it in your database, the key itself is also stored in the database. The problem with this approach is that if your server or database is compromised, it happens more often than you might think, the user is one step away from decrypting your database, thanks to you the key is already there.

This approach is surprisingly common among developers because it’s an easy compromise between “Secure” and plaintext password.

3. Don’t Hash your passwords.

Password hashing is a form of a fingerprint of your password, in this method, you don’t actually store any password in the database, you store the fingerprint (Hash) of the password, so when user tries to sign in to their account you app creates a hash of the password and looks up the hash in the database to see if they match and that’s how your access is verified. This method is much better than previous 2 methods discussed but has some serious flaws if not implemented properly.

First of all, there are many many hashing algorithms out there, some are more secure than others, discussing the pros and cons of hashing algorithms are outside the scope of this article, to minimize the scope of hashing algorithm research, the current industry standard (2018) in terms of safety and difficulty in brute-force and other types of attack, the top three choices are PBKDF2, bcrypt, and scrypt. You should definitely do your own research.

The reason not to rely on Hashing your password, because most people goes with more widely known and less secure hashing algorithms, like MD5, SHA (1, 2, 3). The reason developers go with MD5 and SHA because they are well known and easier to implement and also because it’s less CPU intensive compared to bcrypt and scrypt. Higher computational cost with hashing algorithm also means higher cost of developers, MD5 is many order of magnitude faster to brute force on the same password than scrypt. Which means when you have a large number of users your password lookup on similar hardware will be lower for scrypt. Meaning you will have to invest more in hardware. Which is why some developers generally try to avoid more complexity, but it also makes you vulnerable to Brute-Force, Lookup Tables, Reverse Lookup Tables and Rainbow Tables attacks. Having a poorly implemented hashing is as bad as not having any form of hashing at all.

So What is the best industry practice when trying to store user passwords in the database?

The best approach is a mixture of Hashing + Salting + enforcing mandatory strong password (lowercase letters, uppercase letters, numerals, and special characters with at least 10-12 characters long) + Database server not directly accessible from the internet, preferably on a different server from your web application.

Salting passwords work by adding random strings to password and then hashing it, this means no two same passwords should have the same hash, this along with previously mentioned best practices makes it close to impossible (or very very very time consuming and difficult) to crack a single password, let alone millions of passwords.

If you follow the above-mentioned rule of best password storage practice, you can store your password on the database without encrypting it, because it adds such a high difficulty level. But encrypting the database itself, even if its hashed and salted is not a bad idea. But the important part is to add a process and policy to store your encryption key in a way that it makes it very difficult to infiltrate your database. Which obviously adds a lot more complexity to an already complex password storage system.

Which is why I recommend everyone, if they are starting out and not very experienced with password management and storage system in a secure way, it’s best to offload this to a third party login system.

The post How not to store user passwords appeared first on Slashgeek.