Вы догадываетесь, что будет, если в иерархии классов встретится непараметризуемый/непараметризованный класс?
Например:
public class Test
{
private class A<T> {}
private class B extends A<String> {}
private class C<T> extends B {}
private class D extends C<Object> {}
public static void main(String[] args) throws Exception
{
Class<?> clazz = C.class;
System.out.println(clazz.getGenericSuperclass() instanceof ParameterizedType);
ReflectionUtils.getGenericParameterClass(D.class, A.class, 0); // ClassCastException, а должно было вернуть String.class
}
}
Вакуум — не теплоизолятор (есть 3 вида теплопередачи, в абсолютном вакууме не работают только 2 из них). У него действительно очень низкая теплопроводность (у абсолютного — 0), и конвекции там тоже нет (всё по той же причине — в абсолютном вакууме нет вещества), но зато излучение он пропускает «на все сто».
Есть более изящные приёмы избежать многократного написания имени класса и описать все методы в одном месте. См., например, реализацию и примеры использования Class.create в Prototype.
Логи надо писать, логи. И при необходимости сдавать доблестным органам. Хоть какая-то помощь следствию… если что.
Хотя, с другой стороны, всё равно не докажете, что не подделали их. Если поверят — хорошо, а если нет — …
Упомянутая вами статья — фигня какая-то. Нормальный способ создавать методы — присоединять их к прототипу, а не к this. А статические методы (не использующие this) присоединяют к функции-конструктору:
function NewObj() {}
NewObj.prototype.nonStaticMethod = function ...
NewObj.staticMethod = function ...
Правда, надо сделать поправку на то, что pv считает GB = 230, а dd — понятно что (109). Тогда в первом тесте в терминах dd будет скорость 7.57 GB/c (всё равно разница заметна).
1. По пункту 3: я проверил, порядок точно имеет значение, то есть, указав exec,user, вы действительно получите user,noexec,nosuid,nodev.
2. Я не нашёл у вас флажка, включающего опцию owner. Поэтому предлагаю такую модификацию (с уточнениями):
Кто может монтировать раздел {
Только администратор
Конкретный пользователь
Каждый
}
-->
Кто может монтировать и размонтировать раздел {
Монтировать — только администратор, размонтировать — только тот, кто смонтировал (по умолчанию)
Монтировать — каждый, размонтировать — только тот, кто смонтировал (user)
Каждый может монтировать и размонтировать (users)
}
и ниже 2 флажка
[ ] Разрешить монтировать обычному пользователю, если он владелец файла устройства (owner) [ ] Разрешить монтировать обычному пользователю, если он состоит в группе-владельце файла устройства (group)
Вообще, опции owner и group могут указываться совместно с любой из трёх опций nouser, user, users (nouser — это опция по умолчанию), но с user или users это имеет мало смысла, так как любой пользователь и так может монтировать раздел. Но раз уж указывать можно, то пусть будут отдельными флажками.
1. Мне кажется, было бы интуитивно понятнее, если бы дефолтной строке опций соответствовали все флажки в выключенном состоянии (а для опций со списком было бы явно указано, какая строчка применяется по умолчанию).
И ещё можно дополнительно указать (в скобках или у правого края, или, возможно, отдельным столбцом), какую опцию флажок или элемент списка задействует (см. примеры ниже) — это для общего развития и чтобы избежать возможной путаницы из-за недостаточно ясных формулировок.
Например: [V] Разрешить операции suid и sgid bits --> [ ] Запретить операции suid и sgid bits (nosuid)
(можно переформулировать во что-то вроде «Отключить эффект битов set-user-identifier и set-group-identifier» или «Не принимать во внимание биты set-user-identifier и set-group-identifier»).
[V] Возможность создавать ссылки на девайсы --> [ ] Не интерпретировать специальные файлы как файлы устройств (nodev)
Кто может монтировать раздел {
Только администратор
Конкретный пользователь
Каждый
}
-->
Кто может монтировать и размонтировать раздел {
Только администратор (по умолчанию)
Монтировать — каждый, размонтировать — только тот, кто смонтировал (user)
Каждый может монтировать и размонтировать (users)
}
2. У вас есть флажок «Обновлять время доступа inode для каждого доступа». Но ведь по этому пункту существуют 3 опции: atime (по умолчанию) — это как раз «обновлять время доступа inode для каждого доступа», noatime — не обновлять время доступа вообще, relatime — обновлять время доступа, только если оно указывает на дату более раннюю, чем дата модификации файла (mtime) или чем дата модификации inode (ctime).
Более того, есть ещё опция nodiratime, которая совсем отключает обновление времени доступа для директорий (видимо, может применяться совместно с любой из трёх опций выше).
3. У вас вроде не обрабатывается следующая ситуация: каждая из опций group, owner, user, users неявно включает опции nosuid,nodev (а последние две [user и users] включают ещё и noexec), если вы далее в строке опций явно не укажете обратное (так написано в man 8 mount). Например, указав user, вы на самом деле получите user,noexec,nosuid,nodev. Указав user,exec, получите user,exec,nosuid,nodev. И, насколько я понял, порядок имеет значение, то есть, указав exec,user, вы получите user,noexec,nosuid,nodev.
Например:
public class Test { private class A<T> {} private class B extends A<String> {} private class C<T> extends B {} private class D extends C<Object> {} public static void main(String[] args) throws Exception { Class<?> clazz = C.class; System.out.println(clazz.getGenericSuperclass() instanceof ParameterizedType); ReflectionUtils.getGenericParameterClass(D.class, A.class, 0); // ClassCastException, а должно было вернуть String.class } }Только поправьте «$% флаг события (тестом)» — наверное, имелось в виду «текстом».
Хотя, с другой стороны, всё равно не докажете, что не подделали их. Если поверят — хорошо, а если нет — …
find ~/.mozilla/firefox/ -name '*.sqlite' -exec sqlite3 '{}' VACUUM \;function NewObj() {}
NewObj.prototype.nonStaticMethod = function ...
NewObj.staticMethod = function ...
.entry-info div.vote-for-user a {
display: none !important;
}
$ pv /dev/zero > /dev/null
42,1GB 0:00:06 [7,05GB/s] [ <=> ]
$ dd if=/dev/zero of=/dev/null bs=1M count=40K
40960+0 записей считано
40960+0 записей написано
скопировано 42949672960 байт (43 GB), 4,22341 c, 10,2 GB/c
$ # Ну или с перенаправлением (какая разница :)
$ dd if=/dev/zero bs=1M count=40K > /dev/null
40960+0 записей считано
40960+0 записей написано
скопировано 42949672960 байт (43 GB), 4,2467 c, 10,1 GB/c
unsafeWindowне рекомендуется использовать, особенно, когда можно обойтись без него:window.addEventListener("scroll", function () { ... }, false);1. По пункту 3: я проверил, порядок точно имеет значение, то есть, указав exec,user, вы действительно получите user,noexec,nosuid,nodev.
2. Я не нашёл у вас флажка, включающего опцию owner. Поэтому предлагаю такую модификацию (с уточнениями):
Кто может монтировать раздел {
Только администратор
Конкретный пользователь
Каждый
}
-->
Кто может монтировать и размонтировать раздел {
Монтировать — только администратор, размонтировать — только тот, кто смонтировал (по умолчанию)
Монтировать — каждый, размонтировать — только тот, кто смонтировал (user)
Каждый может монтировать и размонтировать (users)
}
и ниже 2 флажка
[ ]Разрешить монтировать обычному пользователю, если он владелец файла устройства (owner)[ ]Разрешить монтировать обычному пользователю, если он состоит в группе-владельце файла устройства (group)Вообще, опции owner и group могут указываться совместно с любой из трёх опций nouser, user, users (nouser — это опция по умолчанию), но с user или users это имеет мало смысла, так как любой пользователь и так может монтировать раздел. Но раз уж указывать можно, то пусть будут отдельными флажками.
1. Мне кажется, было бы интуитивно понятнее, если бы дефолтной строке опций соответствовали все флажки в выключенном состоянии (а для опций со списком было бы явно указано, какая строчка применяется по умолчанию).
И ещё можно дополнительно указать (в скобках или у правого края, или, возможно, отдельным столбцом), какую опцию флажок или элемент списка задействует (см. примеры ниже) — это для общего развития и чтобы избежать возможной путаницы из-за недостаточно ясных формулировок.
Например:
[V]Разрешить операции suid и sgid bits -->[ ]Запретить операции suid и sgid bits (nosuid)(можно переформулировать во что-то вроде «Отключить эффект битов set-user-identifier и set-group-identifier» или «Не принимать во внимание биты set-user-identifier и set-group-identifier»).
[V]Возможность создавать ссылки на девайсы -->[ ]Не интерпретировать специальные файлы как файлы устройств (nodev)[V]Разрешить запускать бинарные файлы -->[ ]Запретить прямой запуск исполняемых файлов (noexec)Кто может монтировать раздел {
Только администратор
Конкретный пользователь
Каждый
}
-->
Кто может монтировать и размонтировать раздел {
Только администратор (по умолчанию)
Монтировать — каждый, размонтировать — только тот, кто смонтировал (user)
Каждый может монтировать и размонтировать (users)
}
2. У вас есть флажок «Обновлять время доступа inode для каждого доступа». Но ведь по этому пункту существуют 3 опции: atime (по умолчанию) — это как раз «обновлять время доступа inode для каждого доступа», noatime — не обновлять время доступа вообще, relatime — обновлять время доступа, только если оно указывает на дату более раннюю, чем дата модификации файла (mtime) или чем дата модификации inode (ctime).
Более того, есть ещё опция nodiratime, которая совсем отключает обновление времени доступа для директорий (видимо, может применяться совместно с любой из трёх опций выше).
3. У вас вроде не обрабатывается следующая ситуация: каждая из опций group, owner, user, users неявно включает опции nosuid,nodev (а последние две [user и users] включают ещё и noexec), если вы далее в строке опций явно не укажете обратное (так написано в man 8 mount). Например, указав user, вы на самом деле получите user,noexec,nosuid,nodev. Указав user,exec, получите user,exec,nosuid,nodev. И, насколько я понял, порядок имеет значение, то есть, указав exec,user, вы получите user,noexec,nosuid,nodev.