Ubuntu netboot images

Ако горния трик за Debian netinst ви е харесал ето и netboot изображенията за Ubuntu 19.04:
и на 18.10:
и на 18.04 LTS:
и на 16.04 LTS:

Както казах и преди – аз ги харесвам защото мога да си направя инсталация която цялата да се преточи от-до през интернет и да се използват актуални версии на пакетите. Това което не харесвам във традиционната инсталация със големи ISO файлове е, че дори и да направиш прясна инсталация после половината дистрибуция се обновява след първото влизане което губи време.

Ubuntu netboot images

Debian netinst + netboot images

Да не забравя ето линковете към netinst изображенията на новия Debian:


Ако горните изображения са ви идват малко големи за тестове под виртуалки ето и по-малките изображения (10тократно по-малки):


Разбира се ако имате по-нестандартен хардуер (мрежови карти или дискови масиви) по-малките изображения може и да не ви свършат работа защото не идват със всички налични драйвери. Така устройствата няма да могат да се инициализират и намерят съответно.
Аз обаче си ги харесвам защото всичко се точи по интернет така и след инсталация няма нищо за обновяване.

Debian netinst + netboot images

Как да пренасочиш порт 3000 към 80?

Понякога се налага да се пренасочи порт от едно приложение да отговаря на друг. Най-пресния пример е пренасочване на Ruby On Rails който слухти на порт 3000 да работи на порт 80.

Ето как става:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000

Така със нула промени по конфигурацията вече RoR започва да обработва заявки на порт 80.

Как да пренасочиш порт 3000 към 80?

MD/MHD като първо име

От доста време се чудя защо някой азиатци във името си имат Md или Mhd. Дори за известно време си мислех, че е нещо като Dr (доктор) или Eng (инжинер). После си мислех, че е MD (Medical Doctor) при това много сериозно.

Оказа се обаче, че това е късата форма на Muhammad или Mohammad. Може също така и да се види и като Mohd.

MD/MHD като първо име

Safari ITP 2.1 DEMO Showing cookies expiring in 7 days

A few days ago, WebKit announced that the new Safari versions will include an updated version of Intelligent Tracking Prevention 2.1. Here’s a link to the announcement:
Now, with a few tests, I’ll show you how this affects you directly. Below you will also find an example of how to bypass the protection.

First, we will start with an usual test of how a cookie is created locally through an API document.cookie. The file that we will use can be found here:
The methodology is as follows. Upon loading the website, you can see that no cookies appear. After that we create them by pressing the buttons 1-3 and again displaying the cookies. These cookies have an expiry date somewhere around 2021, 2022 and 2023. For convenience, the developer tools have been enabled as to display these same cookies. The images shown are before and after. In the time between the tests the cookies jar has been cleaned as to avoid any interference in the results.

We start with Firefox:

As you can see, the cookies have been created and their expiry dates are several years ahead in the future.

Next comes Chrome:

Similarly, there isn’t any change here. Cookies have several years expiry.

What follows is a desktop Safari (macOS):

And this is where we see ITP in action. Cookies are still the same, but their lives (their expiration is) are limited to a week

Our last test is the Safari (iOS) for mobile. This is where things get a little more complicated. Before the test, let’s first purge the cookie jar. To do that we go to Settings, Safari, Advanced and do the following:


Now that all cookies are purged, we can experiment.

After that, we go back to Settings, Safari, Advanced, Website Data and see that we got some data.

The problem is that we can’t see what these data are. That’s why we need to connect the iOS device with a cable to a macOS and connect to the device from a desktop Safari. Here’s a screenshot:

As you can see, these cookies are capped to a seven day expiry, just like they are for a desktop Safari.

Let’s continue testing this time with the cookies sent by the server itself. For this purpose we will use the following file:
If your are interested in its code here it is:
The methodology here is the following. We load the file, we make a screenshot. We reload the file and make another screenshot.


Here, as you can see the life of the cookies is 10 years.


10 years again.

Desktop Safari (macOS):

Here too we see our cookie with 10 years of expiry.

Mobile Safari (iOS):

Here again we need to connect the iOS with macOS in order to see properly the data.

I intentionally left the old cookies here together with the new ones so that you can see how 3 of them have a life of one week and one (the new one) of them expires in 2029.

Why will this little change play a big role in the future?

Over the years, many tracking, advertising and analytics systems began to systematically abuse online tracing. This is the reason our browsers are stuck from piles of useless cookies that we, as users, do not need at all, they just don’t serve us. The only people for whom cookies carry some information are the owners of the above-mentioned networks.
In fact, just loading an ad code leads to the recording of many many cookies from other advertising networks because of their resale free advertising slots.
Social sharing buttons are another example. When I’m logged on to a social network I have an authentication cookie on my device. And when I visit a site with social sharing buttons in it, based on these cookies, the social network knows which sites I have been visiting.
There are other examples, but let’s not dig into too much technical stuff.

But why will we still be affected anyway?

After the hasty joy of less tracking comes the sad news. Alas, we, as webmasters, will also be affected just because of the use of Analytics products.

The main problem is how these products use cookies. We will take the popular Google Analytics as an example. The use of their cookies is well described here:
For example, we will use 2 scenarios:

  1. This scenario is entering the website from somewhere and performing some action. The simplest example is visiting a site for locksmiths repairs, plumbers or even HVAC repairs. In this case, the user performs usually one action which is most often to find their way on the website and see whether they can use the services for their particiular district. After a phone contact follows. This same visitor may or may not return within the next couple of days. In this case, perhaps 80-90% of the site visits are from new users.
  2. This scenario is a bit more complicated and involves several visits of the user. A simple example is the news publisher or an e-commerce site. In this case the user visits the site from some source – search, ads, social media or directly. Then they continue visiting the website – directly, via search, remarketing, social media, mail marketing, etc. Due to the nature of these visits, it is important to measure the first visit and the user’s entire path across the website in all his returning visits. If this is e-commerce, the duration can be a week, but very often the journey itself can last for weeks or even months. We may also have a one-time purchase or multiple purchases over time.

Traditionally Google Analytics keeps the cookies for 2 years from the moment of the first visit. This is more than enough to measure user activity. This also makes it possible to accordingly analyze the new and the returning users.

The answer to these two scenarios is relatively easy.

In the first case, we have a low interactivity on the website and therefore the the loss of cookies will not affect the measurement of the users. Additionally, the website target audience are their new clients from the website. Having used the service, visitors usually do not return to the website. In fact, these websites are not so pesky for the reporting of the user activity. So if you have a website falling into this category you have nothing to worry about.

In the second case, however, we have a website with high interactivity. Here the loss of cookies is already fatal for the website. From now on, the website will not be able to monitor and measure effectively user activity. It it these websites that are the real danger, entering your personal space. Typically, there is one or more ad networks, one or several analytics scripts, and several tracking scripts. At the same time, they have implemented integration with at least one social network. If you have a website falling in this category, you have all the sufficent grounds to worry about this change.

Is there a fix for this?

Of course!
Here is an example of a fix (together with the code needed for it):
After the first cookie has been generated, if the user uses a login button, the server takes the cookie, changes it and extends its expiry to 2 years.
Here’s an example of desktop Safari too:

And now, let’s make a pseudo login which will extend the life of our cookie to 10 years:

As you can see, you can extend the life of an existing cookie. But, unfortunately, this will require the calling of some code on a server. And many of the tracking, advertisements and analytics products and services use serverless solutions to deliver information to their end customers. Now these services will have to change the way they deliver files to end-users if they want to offer their users the right reporting for Safari users beyond that seven day expiry period.

Of course, the above is not the final solution and such a workaround will work for some time. There is no guarantee that if tomorrow Apple release ITP 2.2 or 3.0, the mechanism will continue to work as it does now.
It is absolutely possible that the final version of the ITP is slightly different and the tests I have made are wrong. But one thing is certain – from now on, the reporting of consumer actions will be one little bit harder than it was before.

Yet, I am a big fan of the slightly anonymous browsing of the Internet. Once a month I clean up all websites data:

Additionally I have set Safari by default to open in private mode:

The same goes for my other iOS devices.

Safari ITP 2.1 DEMO Showing cookies expiring in 7 days

Instagram качване на снимка

Сега ще ви покажа как можете да качвате снимки към Instagram от настолен компютър. Дълго време Instagram позволяваше качване на снимки само от тяхното мобилно приложение. Но пред последните няколко години малко разхлабиха това и позволиха към един акаунт да се привържат още няколко. Ако не се лъжа бройката е до 6. Но какво да направим когато имаме акаунт и трябва да се качи снимка, а разполагаме само със компютър?

Решението е много просто! Сменяте си user agent-a със iOS или нещо от Android което бях описал тук. След което презареждате Instagram:

Така долу по средата се явява икона на +. Натискате я. Излиза прозорец за избор на файл за качване:

След като сте го избрали избирате филтър, намествате снимката и натискате Next. Излиза прозореца за избор на текст, локация и възможност да тагнете някой. Пишете нещо такова:

След което при натискане на бутона Share това се публикува от ваше име на стената ви:

Този подход може да се приложи по няколко начина със цел мащаб. Първия е със използване на Chrome и неговите профили което е описано тук. Друг подход е използване на Firefox и неговите профили което съм описал преди време тук.  Така идеята е, че правим профил Иван и там се логваме със неговите социални акаунти. После правим профил Драган и там се логваме със неговите социални акаунти. Следва профил Петкан където използваме само неговите профили. Разбира се нищо не ви пречи и да имате няколко устройства където да е логнат със тези си акаунти.

Instagram качване на снимка

Chrome забрана на JavaScript

Сега ще ви запозная със една сравнително нова възможност на браузъра Chrome, а именно да се забранява JavaScript на ниво сайт. Във всички браузъри това го има като възможност, но е глобално т.е. пускаш и спираш целия JavaScript, но на ниво браузър. Това води до (д)ефекти примерно ако си отворил Facebook, Twitter, Gmail, Ads, Analytics или други такива тежки сайтове и във следващия момент спреш изцяло JavaScript. Общо взето моментално целия интерфейс става неработещ и това се решава само със включването на JavaScript и евентуалното им презареждане. За да бъдат нещата по-лоши това води и до спиране на интерфейса на Chrome защото приставките са написани на JavaScript, а и част от интерфейса също.

Но във една от последните версии на Chrome излезе възможност да се забрани индивидуално за даден сайт да не може да използва JavaScript. До сега това беше възможно само със използването на специални приставки. Сега ще ви покажа как можете да го направите със голи ръце.

За пример ще ви покажа един сайт който ползва много реклами, но харесвам да го посещавам – Блиц.БГ. Сайта е хубав, информативен и е доста жълт. Всичко това те кара да отваряш нови и нови табове за да проследиш новината. Но на всеки таб има реклами които хабят ценна процесорна мощ, хабят рам и в крайна сметка затормозват компютъра или мобилното устройство.

Първата стъпка е да отворим сайта:
и да кликнем горе на иконата със катинар. След това натискаме „Site settings“. При което ни излиза този прозорец:

Отиваме до JavaScript и избираме „Block“ със което го забраняваме. След което можем да затворим този таб. Вече първия таб изглежда така:
и ни подканя да презаредим.

Какво губим като потребители във този случай? Първо спираме коментарите на сайта, второ – галериите и някой снимки които се зареждат със lazy loading спират да работят и трето малко интерфейса се чупи (ама само малко!). Но всичко бледнее пред възможността да отвориш 30 таба дори и на по-слаб компютър. Отделно сайта в момента изразходва драстично по-малко интернет и се зарежда чувствително по-бързо. Какво губят авторите на сайта – не могат да ми показват реклами и не могат да ме видят във техния Analytics. Всъщност авторите на сайта могат да си решат проблемите като използват технология тип native advertisement и със някакъв трекиращ пиксел да ме отчитат.

Chrome забрана на JavaScript

Смяна на Chrome user agent без плъгин

Понякога се налага да се смени user agent-a без да се използва плъгин. Ето и как можете да го направите без плъгин или някаква друга приставка.

Ето оригинала:

Както виждате user agent-a ми е CrOS което си е ChromeOS. Нека сега да го сменим!

Натискаме десен бутон във файла, Инспект Елемент и от инспектора във долния панел избираме Network Conditions и го сменяме. Ако не е активен Network Conditions се клика на трите точки във ляво и оттам се избира. Ето как би трябвало да изглежда.

И как да се представим за Googlebot mobile:

След презареждане действително заявката се изпраща със този user agent. Това е полезно за тестване на сайтове когато се сервират различни страници във зависимост от браузъра. Отделно е полезно когато се тестват сайтове защото във един прозорец може да се сервира съдържание за iPhone, във друг за iPad, във трети за Android и четвърти да е за компютър със симулиране и на различната мрежа във всеки един от тях индивидуално.

Смяна на Chrome user agent без плъгин