A
я его покупал
Я не говорил, что считаю, что ты бесплатно токен получил.
Size: a a a
2020 June 25
t
Alexander
Я не говорил, что считаю, что ты бесплатно токен получил.
не, я имею в виду покупал токен с ЭЦП. т.е. он не пустой. я с него когда-то давно экспортировал ключ
A
не, я имею в виду покупал токен с ЭЦП. т.е. он не пустой. я с него когда-то давно экспортировал ключ
Чем экспортировал?
t
в УЦ импортировали
A
в УЦ импортировали
А чем ты раньше с токена экспортировал?
t
под вендой при помощи КриптоПро доставал pfx
A
под вендой при помощи КриптоПро доставал pfx
Значит криптопрой же и экспортируй сейчас, если этот те же ключи. У тебя токен является pkcs15 хранилищем. Opensc хранит на нем данные, выставляя наружу pkcs11-интерфейс. То же самое делает и криптопро, но формат контейнеров на pkcs15 у cryptopro и opensc может не совпадать.
A
Ты можешь попробовать глянуть, что за данные там лежат через pkcs15-tool или opensc
t
Alexander
Значит криптопрой же и экспортируй сейчас, если этот те же ключи. У тебя токен является pkcs15 хранилищем. Opensc хранит на нем данные, выставляя наружу pkcs11-интерфейс. То же самое делает и криптопро, но формат контейнеров на pkcs15 у cryptopro и opensc может не совпадать.
Да видимо только так и получится. Проблема только в том, что криптопро у меня сейчас больше нет
t
Alexander
Ты можешь попробовать глянуть, что за данные там лежат через pkcs15-tool или opensc
как это сделать?
A
как это сделать?
man pkcs15-tool
man opensc-tool
man opensc-explorer
man opensc-tool
man opensc-explorer
A
Там некое подобие фс
IG
Дата 2019, не знаю насколько всё это актуально на сегодняшний день. Но там не только это, много чего еще сильно медленнее:
https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=2
https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=2
tl;dr, I can make btrfs look awesome, and I can make it look stupid. It depends
on your workload, but generally speaking a normal Fedora user's workload is
going to feel the same regardless of the file system.
Phoronix is widely ignored and a joke to the fs development community. Facebook
deploys latency sensitive workloads across millions of machines with btrfs. We
do not accept latency regressions, our threshold for performance regressions
depends on the workload, but is generally under 5% and usually 1%.
That's not to say that btrfs is faster always, but that it depends on your
workload. The overwrite case is clearly a loser almost always, unless you use
the nocow file attr on those files. Reads can sometimes have higher latencies,
but that's the price you pay for checksumming. Inside Facebook we run with
compression on everywhere, which reduces the IO sizes both ways, which reduces
the overhead to the point where it's clearly faster than either xfs or ext4.
That's not the sole reason we use compression, but it's a nice way to get around
the cost of checksumming.
I'm currently knee deep in a performance discrepancy issue that WhatsApp has
discovered. However I have to get the file system to the point where it has > 1
TiB of metadata (not data, actual metadata) before I see a difference between
btrfs and xfs for that workload. Before that point it's not even a competition,
btrfs wins hands down. And even then we're talking about maximum latencies, so
every once and a while btrfs appears to go out to lunch for around 500ms for
unknown reasons.
These are the sort of performance investigations that btrfs is having right now,
edge cases under specific workloads. Generally speaking it's on par if not
faster than anybody else, and the cases where it's slower there's a clear trade
off being made for checksumming. Thanks,
Josef
on your workload, but generally speaking a normal Fedora user's workload is
going to feel the same regardless of the file system.
Phoronix is widely ignored and a joke to the fs development community. Facebook
deploys latency sensitive workloads across millions of machines with btrfs. We
do not accept latency regressions, our threshold for performance regressions
depends on the workload, but is generally under 5% and usually 1%.
That's not to say that btrfs is faster always, but that it depends on your
workload. The overwrite case is clearly a loser almost always, unless you use
the nocow file attr on those files. Reads can sometimes have higher latencies,
but that's the price you pay for checksumming. Inside Facebook we run with
compression on everywhere, which reduces the IO sizes both ways, which reduces
the overhead to the point where it's clearly faster than either xfs or ext4.
That's not the sole reason we use compression, but it's a nice way to get around
the cost of checksumming.
I'm currently knee deep in a performance discrepancy issue that WhatsApp has
discovered. However I have to get the file system to the point where it has > 1
TiB of metadata (not data, actual metadata) before I see a difference between
btrfs and xfs for that workload. Before that point it's not even a competition,
btrfs wins hands down. And even then we're talking about maximum latencies, so
every once and a while btrfs appears to go out to lunch for around 500ms for
unknown reasons.
These are the sort of performance investigations that btrfs is having right now,
edge cases under specific workloads. Generally speaking it's on par if not
faster than anybody else, and the cases where it's slower there's a clear trade
off being made for checksumming. Thanks,
Josef
I
tl;dr, I can make btrfs look awesome, and I can make it look stupid. It depends
on your workload, but generally speaking a normal Fedora user's workload is
going to feel the same regardless of the file system.
Phoronix is widely ignored and a joke to the fs development community. Facebook
deploys latency sensitive workloads across millions of machines with btrfs. We
do not accept latency regressions, our threshold for performance regressions
depends on the workload, but is generally under 5% and usually 1%.
That's not to say that btrfs is faster always, but that it depends on your
workload. The overwrite case is clearly a loser almost always, unless you use
the nocow file attr on those files. Reads can sometimes have higher latencies,
but that's the price you pay for checksumming. Inside Facebook we run with
compression on everywhere, which reduces the IO sizes both ways, which reduces
the overhead to the point where it's clearly faster than either xfs or ext4.
That's not the sole reason we use compression, but it's a nice way to get around
the cost of checksumming.
I'm currently knee deep in a performance discrepancy issue that WhatsApp has
discovered. However I have to get the file system to the point where it has > 1
TiB of metadata (not data, actual metadata) before I see a difference between
btrfs and xfs for that workload. Before that point it's not even a competition,
btrfs wins hands down. And even then we're talking about maximum latencies, so
every once and a while btrfs appears to go out to lunch for around 500ms for
unknown reasons.
These are the sort of performance investigations that btrfs is having right now,
edge cases under specific workloads. Generally speaking it's on par if not
faster than anybody else, and the cases where it's slower there's a clear trade
off being made for checksumming. Thanks,
Josef
on your workload, but generally speaking a normal Fedora user's workload is
going to feel the same regardless of the file system.
Phoronix is widely ignored and a joke to the fs development community. Facebook
deploys latency sensitive workloads across millions of machines with btrfs. We
do not accept latency regressions, our threshold for performance regressions
depends on the workload, but is generally under 5% and usually 1%.
That's not to say that btrfs is faster always, but that it depends on your
workload. The overwrite case is clearly a loser almost always, unless you use
the nocow file attr on those files. Reads can sometimes have higher latencies,
but that's the price you pay for checksumming. Inside Facebook we run with
compression on everywhere, which reduces the IO sizes both ways, which reduces
the overhead to the point where it's clearly faster than either xfs or ext4.
That's not the sole reason we use compression, but it's a nice way to get around
the cost of checksumming.
I'm currently knee deep in a performance discrepancy issue that WhatsApp has
discovered. However I have to get the file system to the point where it has > 1
TiB of metadata (not data, actual metadata) before I see a difference between
btrfs and xfs for that workload. Before that point it's not even a competition,
btrfs wins hands down. And even then we're talking about maximum latencies, so
every once and a while btrfs appears to go out to lunch for around 500ms for
unknown reasons.
These are the sort of performance investigations that btrfs is having right now,
edge cases under specific workloads. Generally speaking it's on par if not
faster than anybody else, and the cases where it's slower there's a clear trade
off being made for checksumming. Thanks,
Josef
А есть субтитры к эльфийскому?
A
tl;dr, I can make btrfs look awesome, and I can make it look stupid. It depends
on your workload, but generally speaking a normal Fedora user's workload is
going to feel the same regardless of the file system.
Phoronix is widely ignored and a joke to the fs development community. Facebook
deploys latency sensitive workloads across millions of machines with btrfs. We
do not accept latency regressions, our threshold for performance regressions
depends on the workload, but is generally under 5% and usually 1%.
That's not to say that btrfs is faster always, but that it depends on your
workload. The overwrite case is clearly a loser almost always, unless you use
the nocow file attr on those files. Reads can sometimes have higher latencies,
but that's the price you pay for checksumming. Inside Facebook we run with
compression on everywhere, which reduces the IO sizes both ways, which reduces
the overhead to the point where it's clearly faster than either xfs or ext4.
That's not the sole reason we use compression, but it's a nice way to get around
the cost of checksumming.
I'm currently knee deep in a performance discrepancy issue that WhatsApp has
discovered. However I have to get the file system to the point where it has > 1
TiB of metadata (not data, actual metadata) before I see a difference between
btrfs and xfs for that workload. Before that point it's not even a competition,
btrfs wins hands down. And even then we're talking about maximum latencies, so
every once and a while btrfs appears to go out to lunch for around 500ms for
unknown reasons.
These are the sort of performance investigations that btrfs is having right now,
edge cases under specific workloads. Generally speaking it's on par if not
faster than anybody else, and the cases where it's slower there's a clear trade
off being made for checksumming. Thanks,
Josef
on your workload, but generally speaking a normal Fedora user's workload is
going to feel the same regardless of the file system.
Phoronix is widely ignored and a joke to the fs development community. Facebook
deploys latency sensitive workloads across millions of machines with btrfs. We
do not accept latency regressions, our threshold for performance regressions
depends on the workload, but is generally under 5% and usually 1%.
That's not to say that btrfs is faster always, but that it depends on your
workload. The overwrite case is clearly a loser almost always, unless you use
the nocow file attr on those files. Reads can sometimes have higher latencies,
but that's the price you pay for checksumming. Inside Facebook we run with
compression on everywhere, which reduces the IO sizes both ways, which reduces
the overhead to the point where it's clearly faster than either xfs or ext4.
That's not the sole reason we use compression, but it's a nice way to get around
the cost of checksumming.
I'm currently knee deep in a performance discrepancy issue that WhatsApp has
discovered. However I have to get the file system to the point where it has > 1
TiB of metadata (not data, actual metadata) before I see a difference between
btrfs and xfs for that workload. Before that point it's not even a competition,
btrfs wins hands down. And even then we're talking about maximum latencies, so
every once and a while btrfs appears to go out to lunch for around 500ms for
unknown reasons.
These are the sort of performance investigations that btrfs is having right now,
edge cases under specific workloads. Generally speaking it's on par if not
faster than anybody else, and the cases where it's slower there's a clear trade
off being made for checksumming. Thanks,
Josef
Мы уже с самого утра в оффтопике обсуждаем. :) Присоединяйся. Я стараюсь тоже быть оптимистичным и вы уже даже вынуждаете меня на себе проверить её. 😆
IG
Мы уже с самого утра в оффтопике обсуждаем. :) Присоединяйся. Я стараюсь тоже быть оптимистичным и вы уже даже вынуждаете меня на себе проверить её. 😆
Там 612 новых сообщений
A
ОК, нужно сюда переносить и красиво оформлять, не как выше, форматирование плывет когда копипастишь из рассылки)
A
🔥 Hot тема.
PT
кто знает как хромиум ОС запустить из под виртуалки в линуксе ?
L
кто знает как хромиум ОС запустить из под виртуалки в линуксе ?
Просто берёш и запускаеш