stas8

Дело вкуса.
На домашних машинах делаю так:
/ - под систему (80 gb хватает, как правило, за глаза)
/tmp - 2 gb
/home - максимальное количество пространства
swap - 2-4gb

Ну и попутно.
Если есть два диска, то ничто не мешает указать /home на второй диск, тогда как всё остальное - на первом.
Т.е. если эксперимент не удался и очень хочется переустановить систему (зачем?), то /home останется на втором диске.

А в целом, можно всё и на одном диске.
Форматируем же разделы только те, которые хотим отформатировать.
Зачем форматировать раздел /home?

В данном случае эти разделы ( / , /tmp , swap , /home ) и есть такие вот диски c:, d:, e:...

Если используете саппорт либу, то должны везде использовать android.support.v7.widget.Toolbar.
Обычный тулбар добавлен только в 5й версии, соответственно работать на <5 не будет.

Вместе с JDK можно скачать и исходный код стандартных библиотек джавы. В любой IDE, зажав CTRL и кликнув по имени того, или иного класса, можно перейти к его исходному коду и полюбопытствовать, что же там такое происходить...

В вашем примере мы видим два конструктора, один принимает символьный поток (Reader), а другой - байтовый поток ("сырые" данные) (InputStream).

Scanner предназначен для удобного чтения текста из потока, т.е. ему нужен символьный поток (Reader). А что он делает с байтовым поток? - правильно, оборачивает его в Reader:) И если зайти в код конструктора, то мы это увидем:

public Scanner(InputStream source) {
        this(new InputStreamReader(source), WHITESPACE_PATTERN);
    }

Все просто, в зависимости от доступного вам потока (Reader/InputStream), вы используете соответствующий конструктор Scanner-а. В вашем примере оба варианта делают одно и тоже.

Библиотека java.io состоит из декораторов (паттерн такой), они как матрешки, вкладывая их один в другой, вы добавляете функционал.

Байтовы поток, а нужен символьный? - пффф... обвернули его InputStreamReader. Нужна буферизация? - легко, Обвернули в BufferedReader.

Помимо знаний Java SE, коллекций, многопоточности, CDI и других вещей, обычно требуется знание:

• Servlet API
  
• JSP
  
• JDBC
  
• JPA
  
• Trancsaction API
  
• Java Message Service API
  
• Validation API
  
• EJB
  
• JSF (не всегда)
  
• JDNI
  
• JavaMail API
  

В общем, всё, что входит в JavaEE. Помимо этого, энтерпрайз любит всякие платные сервера приложений, например WebSphere. Так что хотя бы основы работы с ними надо иметь. Ну и естественно, надо знать SQL и уметь работать с СУБД (обычно используют решения от Oracle).
Частенько требуют ещё и Spring. Ну и естественно, знание ant/maven/gradle (реже).

Для примера можешь написать приложения для управления банковскими счетами. Сделай его как EAR-проект. Установи и настрой БД, настрой ORM в проекте. Всю бизнес-логику описывай в EJB, используя всякие remote-интерфейсы, message-driven beans и т.д. Для клиентской части возьми JSF.
Сделай всё безопасно, с транзакциями, с тестами, с разными ролями и уровнями доступа, с возможностью масштабирования и т.д.

Первый подход плох тем, что в нем вы создаете God-object, он берет на себя слишком много ответственности, что противоречит принципу SRP. Класс будет иметь большой размер и в него постоянно будут вноситься изменения при изменении функциональности.

Второй подход почти правильный. Не хватает только интерфейсов UserServiceInterface и ArticleServiceInterface, в которых описаны методы доступа к данным. Обычно такие интерфейсы называются Repository, а не Service. Эти интерфейсы должны быть реализованы в конкретных классах, например OracleUserService и OracleArticleService. Для взаимодействия с БД, данные классы используют только сессию (Session) или соединение (Connection). В вашем примере это DbHandler.

Почитайте про устройство Hibernate. Он использует второй подход.

Потому, что смотреть нужно не только (и не столько) на циферку после i, а на фактические характеристики процессоров. Иной i3 будет шустрее, чем некоторые i7.
cpubenchmark.net/cpu_list.php, в качестве примера.

Простое решение можно реализовать через префиксное дерево. Запихиваем все шаблоны, а потом сравниваем по строчке из множества.

Если требуется сделать разово и на большом объеме данных, я бы поступил так. Определим на строках обычный лексикографический порядок (если есть строка и её префикс, то префикс меньше). Каждому шаблону со звездочкой {s}* сопоставим две строки {s} и {s}$, где $ больше 0 и 1. Шаблону без звезды, просто ставим {s} и {s}&, где & < 0 и 1. А теперь, начиная с первого символа, запускаем цифровую сортировку на строках, полученных из шаблона, + проверяемых строках.

В полученной последовательности шаблоны образуют скобочную последовательность. Все, что находится внутри скобок матчится с соответствующим шаблоном.

Из положительного, это сделать проще, когда строки не влезают в память. Число разрядов на сравнение можно ограничить длиной самого длинного шаблона.