How to become an author
Search
Write a publication
Pull to refresh
37
Karma
0
Rating
@Lex98

User

Send message
Profile Publications 1Comments 185Bookmarks 392
Какие должны быть пароли в 2024 году?

Если 1 пароль можно захешировать за разумное время (а это необходимо чтобы этим пользоваться на практике), то и 10^4 паролей будут хешироваться не долго. Даже если хеширование занимает 1 минуту, то перебор всех четырехзначных цифровых паролей займет меньше 17 часов (и это без ферм карт, а на таком же сервере, что и атакуемые сервис).

Rating is hiddenLook
Какие должны быть пароли в 2024 году?

соль просто сильно увеличивает стоимость взлома

Ну да, сочетание длинного пароля, соли и ресурсоемкого хеша увеличивает эту стоимость до такой, что даже 1 пароль нельзя взломать используя все вычислительные мощности планеты (по крайней мере те, о которых известно) за миллиарды лет. Мне кажется это достаточно хорошо гарантирует сохранность пароля даже при утекших хешах с солью.

Rating is hiddenLook
Какие должны быть пароли в 2024 году?

Как раз весь смысл хеширования паролей (и соли) в том, что даже если база утекла нельзя было эти пароли получить. Точнее можно было, но (на текущем железе) это занимало бы миллиарды лет. Самый простой пример: пароли из одной цифры. Есть всего 10 вариантов, тут ни соль не поможет (слишком мало вариантов, можно быстро проверить все варианты с заданной солью), ни криптографические хеш-функции (если хеш-функция работает адекватное время для проверки одного пароля, то для 10 вариантов она тоже работает за небольшое время). А вот если пароли состоят из 100 цифр, то это уже 10^100, такое уже при всем желании (с использованием всех вычислительных мощностей планеты) не получится, вариантов слишком много. За этим и нужно и использовать длинные пароли (увеличиваем количество вариантов), и использовать медленные и затратные по памяти хеш-функции (увеличиваем время (или стоимость в деньгах) проверки одного варианта), и соль (чтобы нельзя было 1 раз предпосчитать все варианты до длины n и переиспользывать).

Rating is hiddenLook
Правительство РФ опубликовало постановление об электронном воинском учёте, электронные повестки задействуют с 01.11.2024

что же вам сделает нехорошее приложение, утянувшее ваши GPS координаты?

Я боюсь, например, того, что оно может эти данные утечь. И к уже слитым данным добавятся еще и GPS треки маршрута дом-работа-дом, вполне вероятно что и с метками времени. И теперь не только ФСБ может меня найти, а любой человек, кто готов потратить 30 минут и узнать, как сейчас называется бот для пробива. У меня, конечно же, есть полная уверенность в том, что Яндекс (и добрая половина из установленных у меня на телефон приложений) очень серьезно относится к защите персональных данных и в случае утечки они получат ужасающий по своим последствиям штраф в 60 тысяч рублей (не знаю, если в Яндексе хоть 1 сотрудник с ЗП в месяц меньше).

Про требование ФСБ к операторам такси предоставлять прямой к доступ к базе заказов и текущим перемещениям клиентов слышали?

За последние лет 10 я такси пользовался 1 раз. Даже если ФСБ так уж захочется узнать этот мой маршрут я смогу это пережить. А доступ к истории перемещений это уже совсем другое.

Не того вы боитесь, не там у вас маркеры опасностей расставлены

Спасибо за ваше мнение, я сам как-нибудь разберусь чего мне следует бояться и что с этим делать.

Rating is hiddenLook
Правительство РФ опубликовало постановление об электронном воинском учёте, электронные повестки задействуют с 01.11.2024

Так а зачем выдавать, если можно не выдавать? По закону не надо, это проблемы призывника, что у него возможности ознакомиться не было. Как с письмами от налоговой, это ваша проблема, если налоговая по какой-то причине эти письма по другому адресу шлет, счета заблокируют спокойно и потом ходи и доказывай, что это у них в системе адрес неправильный.

Rating is hiddenLook
Правительство РФ опубликовало постановление об электронном воинском учёте, электронные повестки задействуют с 01.11.2024

В чем вранье? Ну вот стою я непонятно где, возле моста, и начинаю звонить и объяснять, эээ... улица..... ээээ.... ну у моста... так, тут киоск еще такой белый, и фонарь... Точный адрес говорите? Сейчас сейчас.... Я перезвоню.

Это ложная дихотомия, Существует не только "удобно через приложение" и "ужас с помощью звонка". Как минимум несколько лет назад яндекс такси можно было и через сайт с компьютера заказать вообще без проблем, не знаю как сейчас. Да даже без этого я предпочту заказать такси через телефон, слишком уж яндексу много данных от меня хочется. У меня уже отдельный телефон для приложений с сомнительными разрешениями есть, а то бесит, что каждому второму доступ к GPS, sms и звонкам нужен. А если еще и к совершению звонков разрешение (и это не приложение для совершения звонков), то это вообще замечательно.

Rating is hiddenLook
Сказ о Python или почему его лучше не выбирать новичкам

Наследование и дженерики понятия не связанные, они друг с другом не связаны и друг на друга не влияют.

Для дженериков есть трейты, они очень хорошо эту задачу выполняют.

Вместо наследования можно использовать композицию (добавлять "наследуемый" тип в качестве внутреннего поля). Чтобы не было так больно копипастить не изменившиеся методы есть, например, delegate.

Еще для снижения количества копипасты есть макросы, даже 2 вида: Macros By Example и процедурные макросы.

Первый тип не сложный, легко пишется, и неплохо помогает, но все же не настолько могущественны как второй тип.

Чтобы макросы второго типа (я просто не уверен, как нормально это "Macro By Example" перевести, чтобы было понятно что это) писать было проще и веселее можно использовать другие макросы, например quote. Вот мой личный пример его использования.

Rating is hiddenLook
Сказ о Python или почему его лучше не выбирать новичкам

Не надо оператор is использовать для сравнения чисел, это не проверка на равенство, а проверка идентичности (т.е. что объект один и тот же) ((0.1+0.2) == 0.3 тоже выведет False).

Вот пример, почему такое его использование приведет к проблемам:

Заголовок спойлера
x = 100
y = 100
print(x is y) # Output: True
print(id(x))
print(id(y))
x += 100
y += 100
print(x is y) # Output: True
print(id(x))
print(id(y))
x += 100
y += 100
print(x is y) # Output: False
print(id(x))
print(id(y))
Rating is hiddenLook
OpenAI транскрибировала более миллиона часов видео с YouTube для обучения GPT-4

Не понятно написал, попробую раскрыть мысль в этом комментарии. Я "подсадил" друзей и родственников на эти программы. Они, как раз, более чем обычные пользователи и GUI могут пользоваться yt-dlp без проблем. Но часто ютуб ломает своё все, из-за чего ломается yt-dlp и мне приходится этим людям объяснять:

  • как и что нужно скачать с гитхаба;

  • как найти расположение файла по ярлыку;

  • куда же этот новый yt-dlp нужно положить

  • и т.д.

То есть люди как раз самые что ни на есть обычные и кроме этого у них особых проблем после начальной настройки нет.

Rating is hiddenLook
OpenAI транскрибировала более миллиона часов видео с YouTube для обучения GPT-4

Для yt-dlp можно без проблем найти отдельные GUI, вроде Open Video Downloader или Seal. Объяснять, как обновить yt-dlp после очередного обновления ютуба сложно, но вполне возможно.

Rating is hiddenLook
Rust — это не «memory safe C»

вы серьёзно считаете такое неадекватное поведение компилятора приемлемым

Это не автор считает, это стандарт так считает.

Rating is hiddenLook
Rust — это не «memory safe C»

Оракл в свое время начал выпуск своей СУБД с версии 2, мотивируя тем, что никто не хочет пользоваться первой версией

Так в этом и проблема. Сам по себе номер версии вообще ничего не значит. Изменение минорной версии не гарантирует, что у кода не изменилось API (хотя для этого есть помощники). Можно тогда просто на версии с датами перейти (вроде 2024.04.1), код надежнее это не сделает, зато выглядит солидно.

Rating is hiddenLook
Rust — это не «memory safe C»

С 0.X.Y версиями ситуация получается странная - даже если библиотека уже готова для использования в продакшен среде, то переход на 1.0.0 создаст много проблем с не очевидными выгодами. Менять мажорную версию без нарушений обратной совместимости странно, т.к. cargo автоматически не обновит версию с 0.X.Y до 1.0.0, что заставляет всех пользователей библиотеки делать это вручную. А из плюсов только то, что версия 1.0.0+ выглядит солиднее.

Rating is hiddenLook
Rust — это не «memory safe C»

Так и написали бы об этом. Все, что в вашем примере кода говорит о том, что там уже есть многопоточность - это три буквы par. А, как в статье и написано, у меня 0 опыта в C++, я понятия не имею, что эта штука сделает. Вместо обвинений в токсичности лучше бы написали такой комментарий, он был бы гораздо полезнее для всех.

Rating is hiddenLook
Rust — это не «memory safe C»

То есть, вы считаете, что эта статья о сравнение Rust и C (даже проигнорируем тот факт, что я так не считаю, просто часто это то, как люди воспринимают Rust. С Python и Golang сравнений больше), подменяете его своим аргументом "в контексте сравнения с C++, потому что считаю сравнение Rust и Си бессмысленным и просто неправильным" и пытаетесь разбить уже свой собственный аргумент? Да это же соломенное чучело.

Rating is hiddenLook
Rust — это не «memory safe C»

Да по вашим комментариям можно целый курс по черри-пикингу сделать. Я даже название придумал - "Краткий курс черри-пикинга или как проигнорировать контекст дискуссии так, чтобы выставить своего оппонента максимальным идиотом".

Если вы забыли (или не знали) контекста и этой дискуссии, то давайте я вам (и всем, кто будет читать это после) расскажу:

  1. у меня в статье есть пример кода, который использует потоки:

    Заголовок спойлера
    let rows = img.rows_mut().collect::<Vec<_>>();
std::thread::scope(|scope| {
    ...
    for (y, chunk) in rows.into_iter().enumerate() {
        scope.spawn(move || {
            ...
            for (x, pixel) in chunk.enumerate() {
                let mut color = Color::default();
                for _ in 0..samples_per_pixel {
                    ...
                }
                *pixel = color.as_rgb(samples_per_pixel);
            }
            ...
        });
    }
});

img.save("image.png").unwrap();

    Там же указаны гарантии языка для этого кода:

    Заголовок спойлера

    • в этом коде нет гонок данных;

    • невозможно написать эту программу так, чтобы получить пересекающиеся задачи;

    • невозможно написать эту программу так, чтобы в момент img.save хоть один из потоков был бы еще жив.

  2. feelamee на это пишет, что "На плюсах это пишется не сложнее" и "Думаю тут не осталось сомнений, что в таком простом варианте, у плюсов и раста примерно одинаковые удобства и безопасность". Если "В плюсах сделаете { } просто и в конце jthread сделает join()." с таким кодом:

    Заголовок спойлера
    std::ranges::for_each(std::execution::par,
                  rows | std::views::enumerate,
                  [](auto const i, auto const& el){
                    // logic  
                  });

  3. На это я отвечаю " А что будет, если не "сделать { }"? И что будет, если не "в конце jthread сделает join()"? Потому, что в Rust это нельзя не сделать, код не скомпилируется". Потому, что я точно знаю, что если не сделать join() для обычного потока, то это чтение и запись без синхронизации, т.е. это сразу UB и сделать join() автоматически при выходе из скоупа это, насколько я знаю, плохая идея.

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

Rating is hiddenLook
Rust — это не «memory safe C»

Вы бы определились уже со своей позицией, а то я только в комментариях к этой статье видел:

Это Rust сообщество токсичное и фанатичное, конечно.

Особенно это смешно, если проследить за последовательностью событий:

Я правильно понимаю, что этот код настолько же безопасен, как "безопасен" и unsafe Rust?

Rating is hiddenLook
Rust — это не «memory safe C»

Но почему то в одном надо рассматривать ситуацию, когда какой-то недотепа допускает глупую ошибку, но в другом можно на это не обращать внимание, ведь там есть слово, которое его ТОЧНО остановит

А вы попробуйте привести пример, когда человек случайно не просто unsafe блок напишет, но еще и случайно напишет такой код, который UB вызовет (спойлер: unsafe блок не выключает никакие проверки, даже если его случайно написать, то ничего не изменится).

Rating is hiddenLook
Rust — это не «memory safe C»

Если слайсы слишком сложно
Go -- язык простой
позволяет быть продуктивным с минимальным знанием языка

Вам бревно в глазу не мешает?

Rating is hiddenLook
Rust — это не «memory safe C»

Так что, что такое "true" в любом случае будет видно сразу.

Только что проверил, golangci-lint run игнорирует такой код (golangci-lint has version 1.55.2):

package main

import (
	"fmt"
	"math/rand"
)

func main() {
	true := rand.Intn(10) > 5
	if true {
		fmt.Println("randomly true")
	}
}

Видимо потому, что true - слишком незначительная часть языка для того, чтобы true было ключевым словом.

Это как view таблицы в базе данных.

Это замечательно, только вот как мне это поможет избежать (это хотя бы можно s[:3:3] починить):

https://go.dev/play/p/7dkrDMD4v9D

package main

import "fmt"

func main() {
    s := []int{2, 3, 5, 7, 11, 13}
    printSlice(s)

    s = s[:3] // limiting len
    printSlice(s)
}

func printSlice(s []int) {
    s = s[0:cap(s)] // random func ignores limit
    fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)
}

Или такой гайзенбаг, когда то, упадет код или тихо будет работать неправильно зависит от того, был ли слайс переалоцирован или нет:

https://go.dev/play/p/Fud-Dmdgq1u

package main

import (
	"fmt"
	"math/rand/v2"
)

type SlidingWindow struct {
	s      []int
	offset int
	size   int
}

func (w *SlidingWindow) next() []int {
	if w.offset > (len(w.s) - w.size + 1) {
		return nil
	}
	t := w.s[w.offset : w.offset+w.size]
	w.offset += 1
	return t
}

func sliding_window(s []int, offset int, size int) []int {
	return s[offset : offset+size]
}

func main() {
	s2 := []int{1, 2, 3, 4, 5, 6}
	if rand.IntN(10) > 5 {
		s2 = append(s2, 7) // panics without append
	}

	sw := SlidingWindow{s2, 0, 3}

	for w := sw.next(); w != nil; w = sw.next() {
		fmt.Println(w)
	}
}
Rating is hiddenLook
12
3
45 ...
910

Information

Rating
Does not participate
Registered
Activity

Your account

Sections

Information

Services

Support
© 2006–2024, Habr