Post Syndicated from original https://bivol.bg/%D0%BF%D0%BE-%D0%B4%D0%BE%D0%B1%D1%80%D0%B5-%D0%BA%D1%8A%D1%81%D0%BD%D0%BE-%D0%BE%D1%82%D0%BA%D0%BE%D0%BB%D0%BA%D0%BE%D1%82%D0%BE-%D0%BD%D0%B8%D0%BA%D0%BE%D0%B3%D0%B0.html
Демократична България излезе с една декларация в Народното събрание. Декларация, в която бяха казани не всички, но някои истини. Не знам колко. Аз не претендирам да знам причините България да…
Post Syndicated from original https://mjg59.dreamwidth.org/59704.html
Last month I wrote about how bearer tokens are just awful, and a week later Github announced that someone had managed to exfiltrate bearer tokens from Heroku that gave them access to, well, a lot of Github repositories. This has inevitably resulted in a whole bunch of discussion about a number of things, but people seem to be largely ignoring the fundamental issue that maybe we just shouldn’t have magical blobs that grant you access to basically everything even if you’ve copied them from a legitimate holder to Honest John’s Totally Legitimate API Consumer.
To make it clearer what the problem is here, let’s use an analogy. You have a safety deposit box. To gain access to it, you simply need to be able to open it with a key you were given. Anyone who turns up with the key can open the box and do whatever they want with the contents. Unfortunately, the key is extremely easy to copy – anyone who is able to get hold of your keyring for a moment is in a position to duplicate it, and then they have access to the box. Wouldn’t it be better if something could be done to ensure that whoever showed up with a working key was someone who was actually authorised to have that key?
To achieve that we need some way to verify the identity of the person holding the key. In the physical world we have a range of ways to achieve this, from simply checking whether someone has a piece of ID that associates them with the safety deposit box all the way up to invasive biometric measurements that supposedly verify that they’re definitely the same person. But computers don’t have passports or fingerprints, so we need another way to identify them.
When you open a browser and try to connect to your bank, the bank’s website provides a TLS certificate that lets your browser know that you’re talking to your bank instead of someone pretending to be your bank. The spec allows this to be a bi-directional transaction – you can also prove your identity to the remote website. This is referred to as “mutual TLS”, or mTLS, and a successful mTLS transaction ends up with both ends knowing who they’re talking to, as long as they have a reason to trust the certificate they were presented with.
That’s actually a pretty big constraint! We have a reasonable model for the server – it’s something that’s issued by a trusted third party and it’s tied to the DNS name for the server in question. Clients don’t tend to have stable DNS identity, and that makes the entire thing sort of awkward. But, thankfully, maybe we don’t need to? We don’t need the client to be able to prove its identity to arbitrary third party sites here – we just need the client to be able to prove it’s a legitimate holder of whichever bearer token it’s presenting to that site. And that’s a much easier problem.
Here’s the simple solution – clients generate a TLS cert. This can be self-signed, because all we want to do here is be able to verify whether the machine talking to us is the same one that had a token issued to it. The client contacts a service that’s going to give it a bearer token. The service requests mTLS auth without being picky about the certificate that’s presented. The service embeds a hash of that certificate in the token before handing it back to the client. Whenever the client presents that token to any other service, the service ensures that the mTLS cert the client presented matches the hash in the bearer token. Copy the token without copying the mTLS certificate and the token gets rejected. Hurrah hurrah hats for everyone.
Well except for the obvious problem that if you’re in a position to exfiltrate the bearer tokens you can probably just steal the client certificates and keys as well, and now you can pretend to be the original client and this is not adding much additional security. Fortunately pretty much everything we care about has the ability to store the private half of an asymmetric key in hardware (TPMs on Linux and Windows systems, the Secure Enclave on Macs and iPhones, either a piece of magical hardware or Trustzone on Android) in a way that avoids anyone being able to just steal the key.
How do we know that the key is actually in hardware? Here’s the fun bit – it doesn’t matter. If you’re issuing a bearer token to a system then you’re already asserting that the system is trusted. If the system is lying to you about whether or not the key it’s presenting is hardware-backed then you’ve already lost. If it lied and the system is later compromised then sure all your apes get stolen, but maybe don’t run systems that lie and avoid that situation as a result?
Anyway. This is covered in RFC 8705 so why aren’t we all doing this already? From the client side, the largest generic issue is that TPMs are astonishingly slow in comparison to doing a TLS handshake on the CPU. RSA signing operations on TPMs can take around half a second, which doesn’t sound too bad, except your browser is probably establishing multiple TLS connections to subdomains on the site it’s connecting to and performance is going to tank. Fixing this involves doing whatever’s necessary to convince the browser to pipe everything over a single TLS connection, and that’s just not really where the web is right at the moment. Using EC keys instead helps a lot (~0.1 seconds per signature on modern TPMs), but it’s still going to be a bottleneck.
The other problem, of course, is that ecosystem support for hardware-backed certificates is just awful. Windows lets you stick them into the standard platform certificate store, but the docs for this are hidden in a random PDF in a Github repo. Macs require you to do some weird bridging between the Secure Enclave API and the keychain API. Linux? Well, the standard answer is to do PKCS#11, and I have literally never met anybody who likes PKCS#11 and I have spent a bunch of time in standards meetings with the sort of people you might expect to like PKCS#11 and even they don’t like it. It turns out that loading a bunch of random C bullshit that has strong feelings about function pointers into your security critical process is not necessarily something that is going to improve your quality of life, so instead you should use something like this and just have enough C to bridge to a language that isn’t secretly plotting to kill your pets the moment you turn your back.
And, uh, obviously none of this matters at all unless people actually support it. Github has no support at all for validating the identity of whoever holds a bearer token. Most issuers of bearer tokens have no support for embedding holder identity into the token. This is not good! As of last week, all three of the big cloud providers support virtualised TPMs in their VMs – we should be running CI on systems that can do that, and tying any issued tokens to the VMs that are supposed to be making use of them.
So sure this isn’t trivial. But it’s also not impossible, and making this stuff work would improve the security of, well, everything. We literally have the technology to prevent attacks like Github suffered. What do we have to do to get people to actually start working on implementing that?
comments
Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=C-YRSqaPtMg
Post Syndicated from original https://lwn.net/Articles/895327/
The 5.18-rc7 kernel prepatch has been
released for testing. Linus says: “So things continue to be fairly
calm, and as such this is likely the last rc before 5.18 unless something
bad happens next week“.
Post Syndicated from original https://xkcd.com/2620/
Post Syndicated from original http://www.gatchev.info/blog/?p=2443
Разказаха ми нещо, което ме замисли.
Във войната в Украйна руската артилерия действа по класическия начин от Втората световна война. Дислоцира се батареята, приготвя се за стрелба и чака заповеди от комбата по какво да стреля. Право на избор къде да се дислоцира, по кого да стреля и т.н. няма – прави се каквото е заповядано. Без заповед само се отбранява, ако я атакуват. (Ако не ѝ е забранено и това.)
Украинската артилерия е пръсната на малки единици – често дори само едно оръдие. Имат (доста голям) район, в който да се дислоцират – те си избират къде точно, кога и къде да се местят и т.н. Централни заповеди почти няма. Вместо тях има приложение за смартфони. Операторите на дронове въвеждат в него координати на забелязаната цел, оръдейците – данни за позицията си, и приложението моментално им дава данни за поставяне на оръдието, за да бъде ударена конкретната цел с висока точност. Стрелят по нея на които оръдия е в обсега и според важността ѝ. Децентрализирано управление на огъня.
Като резултат украинската артилерия често дори успява да надмине руската като ефективност и резултатност. Въпреки че е няколко пъти по-малка, и с изключение на доставените от Запад към 10% от оръдията ѝ, по-стара и по-хилава от руската. Унищожението на руската армия при опитите ѝ за създаване на плацдарм през Сиверски Донец го демонстрира изключително убедително… А в същото време е много по-малко уязвима от руската – единично оръдие се мести и крие много по-лесно, поразява се със стандартна артилерия много по-трудно и т.н.
А толкова ли са изостанали руснаците, че не прилагат същото? Нямат ли си кадърни програмисти?
О-хо-хо! Имат, и още как! 98% от ботнетовете са реализирани и контролирани от руснаци. Вярно е, не от случайни киберкримки, а от поделение 26165 на ГРУ – хакерите на руската армия. Но това ги прави не по-малко, а по-достъпни за военни цели. А киберпрестъпността печели и плаща доста, лесно наема качествен талант, иска се изключително майсторство, за да си водещ сред нея. Очевидно хакерите на ГРУ са.
А защо тогава не го правят?
Защото подобно приложение би нарушило принцип номер едно на руската армия – тя е, за да изпълнява заповеди. В нея личната инициатива се поощрява единствено когато е в изпълнение на конкретна заповед, и дори тогава не винаги. Във всички други случаи се хвали на думи и наказва на дело.
А това е заради един фундаментален факт. Под „капиталистическата“ боя Русия продължава да е феодална държава.
Например в нея изгодните бизнеси се водят юридически собственост на съответните олигарси, но реално са тяхно ленно владение, дадено им за вярна служба. В момента, в който „сеньорът“ прецени, че друг би му служил по-добре, владението преминава в „собственост“ на този друг, срещу непублична сума (като правило нула). Ако настоящият му „собственик“ не е наясно със системата – примерно се заблуждава, че бизнесът е наистина негова собственост – му се случва каквото ще му докаже грешката му (Ходорковски, anyone?). Подобно е положението и с всички други видове „владения“ – високи постове, привилегии и т.н.
Размерът и важността на „владението“ се определя от точно едно нещо – до каква степен „собственикът“ му е над закона. Това не винаги съвпада с обичайните представи. Например типичният армейски генерал командва като минимум бригада, няколко хиляди войници и огромно количество бойна техника, а лейтенантът от „службите“ често няма нито един подчинен и единственото му оръжие е един пистолет. Ако обаче лейтенантът изкомандва генерала да му пази колата, генералът ще го изпълни на мига, въпреки че лейтенантът официално е много далеч под него в йерархията. Просто „службите“, като реално политическа полиция, са благородническа категория безусловно над всички други, тъй като са по-доверени на властта от всички други. Съответно идеята, че можете да им се опънете за нещо, или да ги съдите, би разсмяла нормалния руснак.
Затова за Русия безпрекословното подчинение в армията е от върховна важност. Заради тежкото си въоръжение армията е по-силова институция дори от „службите“, а в същото време е много по-малко доверена на феодалната върхушка. Позволи ли се в нея култура на самоинициатива, върхушката е под заплаха, по-страшна от външните врагове. За всяка феодална върхушка най-страшният ѝ враг е простолюдието, което тя тъпче – а армията е набрана предимно от него… Затова подобна гъвкавост, базирана на самоинициатива, няма да бъде допусната в руската армия дори при риск за загуба на войната.
Накратко, Русия е феодализъм с тънък до прозрачност слой капиталистическа боя отгоре. Докато Украйна е доста несъвършена и дори с феодални остатъци демокрация, но все пак по-скоро демокрация. Затова тя може да си позволи да даде свобода на инициативата на бойците си – може да разчита на лоялността им. Докато Русия няма как да посмее да ѝ разчита.
А свободата на инициативата и гъвкавостта при изпълнение на задачи са огромни предимства в съвременната война. На теория най-ефективното ѝ постижение, интеграцията на видовете оръжия и родовете войски, е чисто командна задача. На практика обаче, подобно на икономиката, съвременната военна обстановка е твърде сложна и динамична, за да може да бъде обхваната адекватно от централизирана командна система. Съответно делегирането на инициатива и децентрализирането на действията носят огромен плюс. През 1982 г. Израел успява да разгроми многократно по-многобройните арабски армии основно защото позволява инициатива и децентрализиране на действията. Това, че израелската армия е въоръжена със западно оръжие, а арабските с руско, също е фактор, но с по-малко значение.
Ето затова Украйна, въпреки че има няколко пъти по-малки човешки и военни ресурси от Русия, има отлични шансове да спечели тази война. Тя е по същество война на капитализма срещу феодализма. Виждали сме я неведнъж, и на военния фронт, и на икономическия, и на социалния. Знаем как свършва.
А и не е зле да се замислим над още нещо. През 2014 г. Украйна успя да изкара от властта част от руските агенти там. Малко, но все пак. Като резултат, за само 8 години доста украинци стигнаха дотам да карат коли, които по българските критерии изглеждат луксозни. И завистливите ганьовци ги плюят за това. Вместо да се замислят защо те не карат такива – и какво е нужно, за да получат един ден тази възможност.
Всъщност, не за да я получат те – за да я получим всички в България… Те няма да го проумеят. Ако бяха способни на това, нямаше да са завистливи ганьовци. Но може би ние, които смятаме себе си за извън тази група, е добре да вземем мерки по въпроса.
Post Syndicated from digiblurDIY original https://www.youtube.com/watch?v=P5op57y5i6k
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=kTElFsXMcco
Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/leadership/
Post Syndicated from Schneier.com Webmaster original https://www.schneier.com/blog/archives/2022/05/upcoming-speaking-engagements-19.html
This is a current list of where and when I am scheduled to speak:
The list is maintained on this page.
Post Syndicated from Alex Krivit original https://blog.cloudflare.com/part1-coreless-purge/
There is a famous quote attributed to a Netscape engineer: “There are only two difficult problems in computer science: cache invalidation and naming things.” While naming things does oddly take up an inordinate amount of time, cache invalidation shouldn’t.
In the past we’ve written about Cloudflare’s incredibly fast response times, whether content is cached on our global network or not. If content is cached, it can be served from a Cloudflare cache server, which are distributed across the globe and are generally a lot closer in physical proximity to the visitor. This saves the visitor’s request from needing to go all the way back to an origin server for a response. But what happens when a webmaster updates something on their origin and would like these caches to be updated as well? This is where cache “purging” (also known as “invalidation”) comes in.
Customers thinking about setting up a CDN and caching infrastructure consider questions like:
This blog will discuss why invalidating cached assets is hard, what Cloudflare has done to make it easy (because we care about your experience as a developer), and the engineering work we’re putting in this year to make the performance and scalability of our purge services the best in the industry.
(i) Scale
The first thing that complicates cache invalidation is doing it at scale. With data centers in over 270 cities around the globe, our most popular users’ assets can be replicated at every corner of our network. This also means that a purge request needs to be distributed to all data centers where that content is cached. When a data center receives a purge request, it needs to locate the cached content to ensure that subsequent visitor requests for that content are not served stale/outdated data. Requests for the purged content should be forwarded to the origin for a fresh copy, which is then re-cached on its way back to the user.
This process repeats for every data center in Cloudflare’s fleet. And due to Cloudflare’s massive network, maintaining this consistency when certain data centers may be unreachable or go offline, is what makes purging at scale difficult.
Making sure that every data center gets the purge command and remains up-to-date with its content logs is only part of the problem. Getting the purge request to data centers quickly so that content is updated uniformly is the next reason why cache invalidation is hard.
(ii) Speed
When purging an asset, race conditions abound. Requests for an asset can happen at any time, and may not follow a pattern of predictability. Content can also change unpredictably. Therefore, when content changes and a purge request is sent, it must be distributed across the globe quickly. If purging an individual asset, say an image, takes too long, some visitors will be served the new version, while others are served outdated content. This data inconsistency degrades user experience, and can lead to confusion as to which version is the “right” version. Websites can sometimes even break in their entirety due to this purge latency (e.g. by upgrading versions of a non-backwards compatible JavaScript library).
Purging at speed is also difficult when combined with Cloudflare’s massive global footprint. For example, if a purge request is traveling at the speed of light between Tokyo and Cape Town (both cities where Cloudflare has data centers), just the transit alone (no authorization of the purge request or execution) would take over 180ms on average based on submarine cable placement. Purging a smaller network footprint may reduce these speed concerns while making purge times appear faster, but does so at the expense of worse performance for customers who want to make sure that their cached content is fast for everyone.
(iii) Scope
The final thing that makes purge difficult is making sure that only the unneeded web assets are invalidated. Maintaining a cache is important for egress cost savings and response speed. Webmasters’ origins could be knocked over by a thundering herd of requests, if they choose to purge all content needlessly. It’s a delicate balance of purging just enough: too much can result in both monetary and downtime costs, and too little will result in visitors receiving outdated content.
At Cloudflare, what to invalidate in a data center is often dictated by the type of purge. Purge everything, as you could probably guess, purges all cached content associated with a website. Purge by prefix purges content based on a URL prefix. Purge by hostname can invalidate content based on a hostname. Purge by URL or single file purge focuses on purging specified URLs. Finally, Purge by tag purges assets that are marked with Cache-Tag headers. These markers offer webmasters flexibility in grouping assets together. When a purge request for a tag comes into a data center, all assets marked with that tag will be invalidated.
With that overview in mind, the remainder of this blog will focus on putting each element of invalidation together to benchmark the performance of Cloudflare’s purge pipeline and provide context for what performance means in the real-world. We’ll be reviewing how fast Cloudflare can invalidate cached content across the world. This will provide a baseline analysis for how quick our purge systems are presently, which we will use to show how much we will improve by the time we launch our new purge system later this year.
In general, purge takes the following route through Cloudflare’s data centers.
Now let’s look at this process in practice. Below we describe Cloudflare’s purge benchmarking that uses real-world performance data from our purge pipeline.
In order to understand how performant Cloudflare’s purge system is, we measured the time it took from sending the purge request to the moment that the purge is complete and the asset is no longer served from cache.
In general, the process of measuring purge speeds involves: (i) ensuring that a particular piece of content is cached, (ii) sending the command to invalidate the cache, (iii) simultaneously checking our internal system logs for how the purge request is routed through our infrastructure, and (iv) measuring when the asset is removed from cache (first miss).
This process measures how quickly cache is invalidated from the perspective of an average user.
We’ve divided our benchmarks in two ways: by purge type and by region.
We singled out Purge by URL because it identifies a single target asset to be purged. While that asset can be stored in multiple locations, the amount of data to be purged is strictly defined.
We’ve combined all other types of purge (everything, tag, prefix, hostname) together because the amount of data to be removed is highly variable. Purging a whole website or by assets identified with cache tags could mean we need to find and remove a multitude of content from many different data centers in our network.
Secondly, we have segmented our benchmark measurements by regions and specifically we confined the benchmarks to specific data center servers in the region because we were concerned about clock skews between different data centers. This is the reason why we limited the test to the same cache servers so that even if there was skew, they’d all be skewed in the same way.
We took the latency from the representative data centers in each of the following regions and the global latency. Data centers were not evenly distributed in each region, but in total represent about 90 different cities around the world:
The global latency numbers represent the purge data from all Cloudflare data centers in over 270 cities globally. In the results below, global latency numbers may be larger than the regional numbers because it represents all of our data centers instead of only a regional portion so outliers and retries might have an outsized effect.
Below are the results for how quickly our current purge pipeline was able to invalidate content by purge type and region. All times are represented in seconds and divided into P50, P75, and P99 quantiles. Meaning for “P50” that 50% of the purges were at the indicated latency or faster.
Purge By URL
| P50 | P75 | P99 | |
|---|---|---|---|
| AFRICA | 0.95s | 1.94s | 6.42s |
| APAC | 0.91s | 1.87s | 6.34s |
| EEUR | 0.84s | 1.66s | 6.30s |
| ENAM | 0.85s | 1.71s | 6.27s |
| OCEANIA | 0.95s | 1.96s | 6.40s |
| SA | 0.91s | 1.86s | 6.33s |
| WEUR | 0.84s | 1.68s | 6.30s |
| WNAM | 0.87s | 1.74s | 6.25s |
| GLOBAL | 1.31s | 1.80s | 6.35s |
Purge Everything, by Tag, by Prefix, by Hostname
| P50 | P75 | P99 | |
|---|---|---|---|
| AFRICA | 1.42s | 1.93s | 4.24s |
| APAC | 1.30s | 2.00s | 5.11s |
| EEUR | 1.24s | 1.77s | 4.07s |
| ENAM | 1.08s | 1.62s | 3.92s |
| OCEANIA | 1.16s | 1.70s | 4.01s |
| SA | 1.25s | 1.79s | 4.106s |
| WEUR | 1.19s | 1.73s | 4.04s |
| WNAM | 0.9995s | 1.53s | 3.83s |
| GLOBAL | 1.57s | 2.32s | 5.97s |
A general note about these benchmarks — the data represented here was taken from over 48 hours (two days) of RUM purge latency data in May 2022. If you are interested in how quickly your content can be invalidated on Cloudflare, we suggest you test our platform with your website.
Those numbers are good and much faster than most of our competitors. Even in the worst case, we see the time from when you tell us to purge an item to when it is removed globally is less than seven seconds. In most cases, it’s less than a second. That’s great for most applications, but we want to be even faster. Our goal is to get cache purge to as close as theoretically possible to the speed of light limit for a network our size, which is 200ms.
Intriguingly, LEO satellite networks may be able to provide even lower global latency than fiber optics because of the straightness of the paths between satellites that use laser links. We’ve done calculations of latency between LEO satellites that suggest that there are situations in which going to space will be the fastest path between two points on Earth. We’ll let you know if we end up using laser-space-purge.
Just as we have with network performance, we are going to relentlessly measure our cache performance as well as the cache performance of our competitors. We won’t be satisfied until we verifiably are the fastest everywhere. To do that, we’ve built a new cache purge architecture which we’re confident will make us the fastest cache purge in the industry.
Through the end of 2022, we will continue this blog series incrementally showing how we will become the fastest, most-scalable purge system in the industry. We will continue to update you with how our purge system is developing and benchmark our data along the way.
Getting there will involve rearchitecting and optimizing our purge service, which hasn’t received a systematic redesign in over a decade. We’re excited to do our development in the open, and bring you along on our journey.
So what do we plan on updating?
The first version of our cache purge system was designed on top of a set of central core services including authorization, authentication, request distribution, and filtering among other features that made it a high-reliability service. These core components had ultimately become a bottleneck in terms of scale and performance as our network continues to expand globally. While most of our purge dependencies have been containerized, the message queue used was still running on bare metals, which led to increased operational overhead when our system needed to scale.
Last summer, we built a proof of concept for a completely decentralized cache invalidation system using in-house tech – Cloudflare Workers and Durable Objects. Using Durable Objects as a queuing mechanism gives us the flexibility to scale horizontally by adding more Durable Objects as needed and can reduce time to purge with quick regional fanouts of purge requests.
In the new purge system we’re ripping out the reliance on core data centers and moving all that functionality to every data center, we’re calling it coreless purge.
Here’s a general overview of how coreless purge will work:
We believe this re-architecture of our system built by stringing together multiple services from the Workers platform will help improve both the speed and scalability of the purge requests we will be able to handle.
We’re going to spend a lot of time building and optimizing purge because, if there’s one thing we learned here today, it’s that cache invalidation is a difficult problem but those are exactly the types of problems that get us out of bed in the morning.
If you want to help us optimize our purge pipeline, we’re hiring.
Post Syndicated from Techmoan original https://www.youtube.com/watch?v=PJakX_-HBqY
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=7K6gIP4qfys
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/05/friday-squid-blogging-squidmobile.html
The Squidmobile.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Read my blog posting guidelines here.
Post Syndicated from Йоанна Елми original https://toest.bg/editorial-9-14-may-2022/
България преживя още една седмица на протести и контрапротести. Още в първите страници на романа „Керван за гарвани“ провинциалният герой на Емине Садкъ гледа столични граждански шествия по телевизията и си мисли: „Все едно живеем в паралелни държави.“ Този път едната държава подкрепя Украйна в контекста на руската инвазия, а другата подкрепя Русия, само че я е срам да си каже, та вместо това говори за „неутралитет“ и „опазване на мира“, без да има ясна дефиниция какво означава това и как то да бъде постигнато. Ако се окажете разкъсани между двете Българии и се губите в океана от (дез)информация, напомням, че в България има няколко работещи инициативи за проверка на факти, които следят твърдения както от проукраински източници, така и от проруски.
„Войната в Украйна извади принудително от хибернацията българските управляващи, заставяйки ги не просто да изберат отбор, но и да играят в него. Правителството на четворната коалиция не беше готово за суровата реалност – ударите отвън и отвътре. На дневен ред излязоха проблеми, чиито решения не бяха системно и целенасочено търсени досега, като енергийната диверсификация; боеспособността на българската армия; кампанията относно еврозоната (предвид присъединяването от 1 януари 2024 г.); руската хибридна война като национална и европейска заплаха. Тук е и темата за българското вето за Северна Македония, с начертаните от по-рано червени линии в Договора за добросъседство от 2017 г. и грешката тя да бъде оставена „на концесия“ на ВМРО“, пише Емилия Милчева в тазседмичния си анализ, озаглавен „Войната в Украйна извади България от хибернацията“.
България прави цивилизационен избор под напрежение, което има своите последствия. Емилия сравнява правителството с изправен до стената човек под дулото на пистолет, готов да обещае всичко всекиму. Остава и въпросът с енергийната диверсификация, тъй като за повече от десетилетие под управлението на Бойко Борисов България не взе стратегически полезни решения за енергийните си източници и остава зависима – над 85% от руския газ, 70% от петрола и 100% от руското ядрено гориво. Краткосрочните решения би трябвало да стигнат за тази зима, но Емилия се пита какво е решението в дългосрочен план. Нужна е политическа воля, категорична е тя.
Но политическата и обществената воля се захранват взаимно, а българското общество няма инструментите за преоценка на връзката си с Русия на Путин, която е пряка наследница на СССР. Това стана ясно от проучване, според което едва 10% от българите са категорични, че познават историята на българо-руските отношения. „Ключът е заровен в градинката на българското масово образование, по-скоро в неговата архаичност, скука, дехуманизация, пропаганда, подчиненост на руски митологеми, развод с европейските ценности и в крайна сметка абсолютно безсмислие, ако целта му е да направи децата едни свободни хора, които могат да намерят мястото си в света“, коментира журналистката Надежда Цекулова в личния си профил във Facebook. И в политиката, и в образованието – време е за излизане от хибернацията.
За едни други две Българии – отпреди десетилетие, напомня и Светла Енчева в текста си „Как МВР си отглежда антидържавна агресия“. Тогава и сега методите са едни и същи, само „враговете“ се променят. „Този път потърпевшите не са мюсюлмани, защото точката на конфликт е друга – подкрепящи Русия срещу подкрепящи Украйна. Друга разлика спрямо 2011 г. е, че сега отговорността на МВР е по-голяма от тази на местната власт. Защото привържениците на режима на Путин дори нямат нужда от официално разрешение, за да постигат с помощта на органите на реда това, което искат“, пише Светла.
Активистите на „Възраждане“ са добре охранявани от полицията, независимо дали акциите им са съгласувани със законовия ред, или не. Не същото може да се каже за подкрепящите Украйна. „Призивите за нападение, насилие и промяна на конституционно установения ред у нас обаче никак не са безобидни. МВР, изглежда, не си е научило урока, че вербалната агресия има свойството да прераства във физическа, ако не бъде спряна навреме“, предупреждава Светла.
Темата на тазседмичния обзор се завърта около политическото и общественото като взаимосвързани явления. Случайно или не, именно това е в основата на интервюто на Слава Савова с политолога Тобиас Флесенкемпер от немската организация Rheinischer Verein.
Рубриката на Слава „Опазване и граждански мобилизации“ е фокусирана именно върху историческото наследство от втората половина на ХХ в. в Европа през призмата на архитектурата, тоест индиректно се връщаме обратно към темата за историята и нейното (не)познаване. Флесенкемпер разказва за конкретни инициативи за опазване на паметниците на културата, за гражданското участие в тях, както и за съвместимостта на прехода към по-екологични градове със запазването на историята. „Когато изчезнат старите сгради около нас, тогава се появяват и политически рискове. Когато историята може да бъде пренаписана, тя може да бъде и отречена – няма да има вече останали артефакти и всичко може да се превърне в практични решения“, казва той в интервюто.
Артефакт е и интервюто на Марин Бодаков с норвежкия писател Даг Сулста. Изпрати ни го Даря Хараланова от издателство „Аквариус“, а в придружаващото писмо тя обяснява защо чак сега то стига до нас: „80-годишният Сулста не използва имейл, поради което от агенцията трябваше да разпечатат на хартия въпросите на Марин, да ги изпратят на писателя по обикновената поща и пак по нея да изчакат отговорите, да ги наберат на компютър и да ги изпратят обратно на нас. Получих отговорите в началото на октомври, месец след като Марин внезапно ни напусна. Оттогава държа този файл в компютъра си…“ В това интервю Марин разговаря с Даг Сулста за романа му „Т. Сингер“, издаден на български в началото на миналата година.
Ако тази препоръка не ви стига, имаме и още. В рубриката „По буквите“ Зорница Христова ни представя „Синята китара“ от Джон Банвил, „Изобретяване на самотата“ от Пол Остър и „Трохи на хартия“ от Марий Росен. Вземете Банвил заради красотата на езика и един главен персонаж, който няма да харесате, но който ще ви научи на много неща. Подхванете Остър, ако ви се чете криминален роман, но и висока литература. Зорница ни издава, че Банвил също пише криминални романи, но „ако той ги отделя в две различни литературни персони, Остър предпочита да играе с пресечните точки между тях“.
Съвсем различна е книгата „Трохи на хартия“ на Марий Росен, с минималистичните илюстрации на Александра Георгиева. За Зорница стихотворенията на театралния режисьор „изглеждат наистина като трохи – малки, състоящи се в повечето случаи от едно-единствено хрумване, най-често образ или смислов обрат“. Тя допълва обаче, че трохите „имат свойството да се слепват; нервните пръсти да ги омачкат в топче хляб, което внезапно и почти неволно придобива черти“.
И понеже ни е тръгнало книжно – Нева Мичева отговори на читателски въпрос за четенето, писането и дали някога на нея самата ѝ е хрумвало да напише книга. Нева винаги се представя най-добре през думите си, затова ви предлагам просто кратък цитат:
„Аз вечно съм неустоимо привлечена от отделни думи, специфични понятия, части от тела или странни ракурси към здания, прехласната по драматично окапващи цветя, подслушани размени на реплики, предмети в неочакван контекст – твърде погълната от нетипичности и детайли, за да погледна към хоризонта и да начертая пътечка, камо ли магистрала. Вниманието ми е котешки нетрайно, възторзите ми – кучешки бурни, а за писането на книги сякаш се иска по-структурирано и структуриращо съзнание за света. Което ми е известно не само от четенето, разбира се, а и от дългата ми работа като преводачка, в която върша същото като писателите, само дето съм спасена от определени творчески мъки, включително тези на суетата.“
Тази седмица нямам много препоръки за вас, скъпи читатели – чета стихотворения на Мария Вирхов и Константин Павлов, препрочитам публицистиката на Алеко Константинов и фрагментите на Атанас Далчев. Изобщо – някак майско и безвременно е всичко. Или може би сме твърде изтощени от близо три месеца война и търсим отговори в миналото, а каква по-добра призма от историята и литературата.
Не съм съвсем сигурна, че мостовете между двете Българии може да бъдат построени без държавно участие – някои от най-популярните мерки за преодоляване на поляризацията включват организирането на граждански събрания или гласуване за проблеми вместо за партии. Към този момент нямаме решение за медиите, които промотират алтернативни реалности с цел печалба и сензация, нито за политиците, които експлоатират една или друга слабост – често чрез дезинформация – за своя цел. Литературата и историята обаче съществуват отвъд времето и ограниченията на физиката (или на обществата ни).
Това напомня и Петър Бакалов с публикувания от него откъс от „Строителите на съвременна България“ на Симеон Радев, който като нищо можеше да бъде написан и днес. Може би някъде из страниците се крият отговорите за настоящето. Във всички случаи – продължаваме да търсим решения. И да говорим. Пък дано се чуем или поне се срещнем някъде между паралелните светове.
Post Syndicated from Нева Мичева original https://toest.bg/gondwana/
Много обичам художествената литература, четенето и писането. Като дете често се разболявах, затова не съм ходила на детска градина, а и целия първи клас почти го пропуснах заради болести. Но баба ми ме научи да чета, докато бях още на пет – тя също беше голям читател на художествена литература, – и оттогава книгите все са ме спасявали, били са ми приятели, утешавали са ме в трудности и са ми давали надежда и смисъл.
Може би заради четенето обикнах и писането. То ми дава идентичност и ме кара да се чувствам истинска. Само пишейки, успявам да изразя всичко, което искам да кажа; да разбера какво мисля и в какво вярвам. Учих журналистика и известно време писах статии за култура – много ми харесваше и ме правеше щастлива. За съжаление, този период приключи преди повече от 15 години.
Отдавна и по прозаични причини работата ми няма нищо общо нито с културата, нито с журналистиката. Продължавам да чета, за щастие, и като че ли с годините гладът за книги става все по-голям. Страхът, че няма да ми стигне времето да изчета всичко, което искам – също. Затова гледам да се придържам към класиката или към утвърдени имена, рядко пресягам към автори, за които не съм чувала или не са ми били препоръчани от някого, на чиято преценка се доверявам. Любим писател от ученическите ми години досега остава Умберто Еко, по-късно открих и обикнах и Амос Оз, Орхан Памук, Исабел Алиенде, Елена Феранте, Хари Мюлиш. Харесвам и съвременни български автори, като Георги Господинов и Теодора Димова.
Но писането ми липсва – като че ли губя огромна част от себе си, не съм си вярна, когато и защото не пиша. Много ми се иска да започна да пиша разкази или дори опит за роман, но сякаш не ми стига смелост, не искам да направя нещо посредствено и недостатъчно добро. Не искам да бъда от графоманите, които смятат, че имат нещо много важно за казване, но не създават нищо стойностно. В същото време съзнавам, че ако винаги се стягам по този начин и не опитам, никога няма и да разбера на какво наистина съм способна.
Ти мислила ли си някога да напишеш книга? Имам предвид книга с истории, преживени или измислени, литература?
Прегръдки и бъди щастлива!
А.Х.
Както превеждам, се спъвам в Предкордилерите – така ли да ги дам, или да кажа „предпланината на Андите“, или нещо трето, по-леко за изговаряне и понятно от пръв поглед за българския читател? Зачитам се в описанието им и попадам на името на праконтинента, който съм чувала да се споменава само в училище. Гондвана! Произнасям го с най-дълбокия си глас (как иначе?), после се смея на себе си, после пращам (без обяснения) съобщение на мексиканската си приятелка: Gondwana! После тържествено, тътнещо, натежало от динозаври и папрати, това име се връща дни наред в ума ми с все същия вкус на приключение и радост.
Един приятел в Аржентина превежда дълго стихотворение на Константин Павлов на испански. Пише ми: „Забих. Не знам какво да я правя тази дума.“ И ми праща откъс: героят си спомня как в далечни краища, „гонен от глад и липса на патриотизъм“, е срещнал „разни непознати животинки“, сред които и бялата пъргава Хермелин, която, „калчица срещне ли, спира и не мърда по-нататъка“, понеже не желае да се цапа. Приятелят е оцветил в жълто „калчица“. Умалително ли е, гальовно ли – то не е просто „някаква кал“, не е и задължително мръсотия, а природа, две стихии в една шепа: какво да кажа на Еухенио за тази нежност към мократа пръст? И дни наред – с малко топло „пльос“ по никое време – „калчица“ се редува в ума ми с „Гондвана“.
Мила А., това не е увертюра, а отговор на въпроса „Мислила ли си да напишеш книга?“. Аз вечно съм неустоимо привлечена от отделни думи, специфични понятия, части от тела или странни ракурси към здания, прехласната по драматично окапващи цветя, подслушани размени на реплики, предмети в неочакван контекст – твърде погълната от нетипичности и детайли, за да погледна към хоризонта и да начертая пътечка, камо ли магистрала. Вниманието ми е котешки нетрайно, възторзите ми – кучешки бурни, а за писането на книги сякаш се иска по-структурирано и структуриращо съзнание за света. Което ми е известно не само от четенето, разбира се, а и от дългата ми работа като преводачка, в която върша същото като писателите, само дето съм спасена от определени творчески мъки, включително тези на суетата.
За превода като професия и неговата етика, естетика, подводни камъни и фантастични възможности мисля много и редовно – длъжна съм да имам теория, освен практиката; да мога да представя верую и устав. А писането (моето) никога не ме е занимавало особено. Периодично изпитвам потребност да разкажа някакви работи на определени хора. И го правя. За мен идеалният вариант е да прехвърля възможно най-много информация, включително емоционална; още от първите редове да покажа ясно що за повествовател съм и с колко голяма щипка сол може да ми се вярва; да не се повтарям; да не ползвам принуда (парична например: любовното везане на един текст е трудоемко дело и вярвам, че трябва да бъде възнаградено, но след прочит и евентуално чувство за благодарност, не преди). И горе-долу толкоз.
Но аз говоря за публикации в пресата, за гмуркания в реалното и лов на перли (всъщност по-често събиране на мидички). А ти – за литературата като трансформация, облагородяване и овладяване на даденостите. Тоест за едно начинание, което, погледнато откъм крайните резултати на толкова много отлични автори по света, може да изглежда плашещо. Защо обаче да го гледаме оттам? Чета писмото ти (благодаря за сърдечните думи в началото и в края – свидливо ги оставям само за себе си – и за доверието по средата) и ми идват и други въпроси. Ако не можеш да се занимаваш изключително с култура и журналистика, защо не го правиш неизключително, с публикации от време на време? Щом се разпознаваш най-добре в писането, но му „изневеряваш“, значи ли, че от 15 години живееш във форсмажор, който не ти позволява да бъдеш дори за малко каквато искаш да си? Или си намерила други изяви, които вече ти се струват твърде обикновени, понеже са достъпни? Или чак сега, след натрупването на липсата, я усещаш конкретно и я формулираш, за да можеш час по-скоро да я запълниш?
И още. Какво толкова ще стане, ако не прочетеш всичко, което си си наумила? Щеше ли да има класици, ако някой не се беше жертвал да ги прочете, без друг да ги е препоръчал? Високото качество и радушният прием не са ли преди всичко следствие – хем незадължително – от къртовския труд по създаването на нещо? Какво е най-излагащото, което може да разкриеш за себе си, ако напишеш книга и я хвърлиш в света? Съществува ли човек, чиято убеденост във важността на нещата, които му иде да каже, остава неизменна през целия му живот? Има ли каквото и да било, което да е стойностно за всички? (Преди 20 години моят любимец Роберто Боланьо казва по телефона на познат журналист – който после го цитира на всеослушание, – че твоята любимка Исабел Алиенде е не просто лоша писателка, а драскачка, и че да я удостоят с националната награда за литература на Чили е все едно да дадат „Пулицър“ на Джон Гришам. Алиенде го нарича „неприятен господин, който злослови за всички“.)
На въпроса „Защо пишете?“, зададен му от вестник „Република“, Умберто Еко отговаря: „Защото ми харесва.“ В същия материал отговарят и други. „За да вкарам малко ред в хаоса“ (Нейтън Ингландър); „Защото светът още не е завършен и не всички истории са разказани“ (Колъм Маккан); „Не съм избирала да пиша. То е като да се влюбиш. Знаеш, че не е добра идея, не знаеш как се е стигнало дотам, но просто си длъжен да се пробваш…“ (Амели Нотомб); „Пиша, защото четенето в детството ми доставяше безкрайно удоволствие, позволи ми да преживея какви ли не вълнения, преобърна живота ми по такъв удивителен начин, че имам чувството, че литературното ми призвание се роди именно от огромното щастие, което изпитвах тогава…“ (Марио Варгас Льоса). А Антонио Табуки цитира Самюъл Бекет: „Не ми остава друго.“ Сигурна съм, че някои от тези заявления ще ти се сторят банални, други – надменни, трети – като взети от собствената ти уста. Не съм сигурна кои, но вярвам, че няма значение. Всяка причина да правиш онова, от което ти е по-добре на този свят, е валидна.
Има нещо много красиво в обстоятелството, че се чувстваш истинска именно през фикцията, една от най-директните и сложни форми на неистина. И нещо много достойно в свенливостта, с която казваш, че ти се иска да напишеш не роман, а „опит за роман“. Докато озаглавявам този текст по любов вместо по логика, се сещам за единствената голяма разлика между превод и писане на художествена литература, която успях да открия през годините. Ето я. На въпроса „Защо?“ в превода никога нямаш право да отговаряш със „Защото така“, а в писането понякога имаш. Желая ти много от това сладко своеволие, А.
Прегръдки и от мен и поздрав с майско ойларипи. Преди месеци същият аржентински колега Еухенио, когото споменахме, зает с превода на друго стихотворение от Павлов, ми писа да пита какво са „ойларипащите старчоци“. Убедена, че „ойларипи“ е международен планинарски възглас, тръгнах да търся източник, с който да подкрепя обяснението си. И с удивление открих, че възгласът си е български – несвързано съчетание от гласни и съгласни, заимствано от алпийските йодлери. Желая ти и много от тези нечакани съкровища, които преводачите така обичаме.
Post Syndicated from Зорница Христова original https://toest.bg/po-bukvite-banville-auster-rosen/
превод от английски Иглика Василева, София: изд. „Лист“, 2022
Първото нещо, което ще чуете по отношение на Банвил, е възхвала на стила – и действително с първите редове се усеща почти плътско удоволствие от думите, от сложните хармонии на изреченията; сетивно удоволствие от езика, като от храна с наситен вкус или миризма във въздуха; наново пробудено сетиво. Това е литература, която се интересува от литературата, от смисъла да бъде именно това, а не просто „транспортно средство“ за предаване на съдържанието. „Наричайте ме Автолик“, започва „Синята китара“. Здравей, Мелвил. Колко ли други препратки изпускам?
Второто нещо, което ще чуете, е любопитен факт: освен тази сочна, напоена с ароматен език проза, Банвил пише и криминални романи под псевдоним. В тях има това, което тук е оскъдно – структуриран сюжет, фабулни фибули, фокусиращи вниманието на онези, които обичат да следят какво се случва. В „Синята китара“ то не е много: застаряващ художник, който някога е бил известен, но сега е изгубил вяра в изкуството си, извършва дребни кражби и между тях открадва жената на свой приятел от детинство, след като собственият му брак е отчужден подир смъртта на детето му. Не особено морален и без добро мнение за себе си – читателят може да го почувства сроден, но не и да го хареса. Оливър Орме се стреми, макар и колебливо, към собствената си разруха; той иска да бъде хванат, да принуди обстоятелствата да го тласнат към развръзка, завършеност, която му убягва по отношение на изкуството.
Всъщност Орме натрапчиво естетизира връзката си със света – не само когато се колебае дали е важно нещото-в-себе си (здравей, Хайдегер), или собственото му възприятие за него, или онова, в което може да го превърне, след като го смели „като боа“, или онова, което трябва „да те лъха от платното“, без да бъде изобразено в чист вид. Да, Орме като че ли минава през различни разбирания за изкуството, за модерното изкуство, докато се самопрезира, докато разревава любовницата си, вечеря с приятеля, когото мами, или пикае през прозореца.
Освен това натрапчиво вижда – продължава да вижда света в богати детайли, независимо от емоционалния заряд на ситуацията, и това го прави да изглежда отчужден и жесток. Но защо го прави?
Винаги съм смятал, че един от най-страшните аспекти на смъртта, настрана от ужаса, болката и нечистотиите, е фактът, че когато няма да ме има, друг не ще може да вижда света, както аз го виждам.
Или вижте това описание на състоянието на творчество:
… едновременно като в транс и с прояснено съзнание, усещащо и най-минималните нюанси, и най-фината игра на цветове, линии и форми. Жив! В края на краищата не беше ли това животът, който не бях разпознал?
Това като че ли е основният страх, който движи героя – паническо събиране на доказателства, че е жив. Затова и не се гнуси нито от кражбите (дребни, но задължително осезаеми), нито от паразитите по миртата на жена си (опитва се да я убеди, че техният живот е даже по-ценен от този на цветето, тъй като те са много), нито от плъха, заселил се в къщата от детството му (дори му купува храна). Липсата на вяра в морала идва от липсата на вяра в реалността. Което ни води до огледалата.
Орме вижда любовницата си в огледалото до тоалетната и в този момент разбира, че тя му е чужда, не я познава истински; докато се възхищава от изискан млад мъж в Париж, военен камион с прикрепено към него огледало прерязва темето на мъжа; Орме се пита дали е видял отражението си в тези последни секунди; към края на книгата разсъждава за невъзможността да се види откъм гърба дори чрез система от огледала, като пояснява: „… със сигурност няма да се видя, както другите ме виждат. Не мога да се държа естествено пред огледало, всъщност никъде не мога да се държа естествено, но най-вече пред огледало“.
Като една наивна (че и сантиментална) читателка се изкушавам да виждам Орме като огледален образ на Банвил; не само заради първото лице, не само заради картините, които всъщност са рисувани с думи (и следователно изкуствоведските терзания се отнасят за тях), не само защото Орме обича да рови из езика, признава си, че се поддава на изкушението да иззоби речника, че се кефи на думи като „ламперия“ и „цокъл“, а и защото гласът на разказвача е и „система от огледала“, в която авторът може да се види отстрани… макар и никога да не може да се държи естествено.
Разкошен е преводът на Иглика Василева; признавам, че ми е любопитно да надникна в оригинала, за да видя каква е била играта на думи зад „рисувам“ и „рискувам“, как точно са се люлели фразите на английски. Но това го знаем и от другите ѝ преводи, включително на Банвил – на български са излизали вече „Древна светлина“, „Безкрайностите“, „Недосегаемият“ и „Сняг“.
превод от английски Иглика Василева, София: изд. „Колибри“, 2022
Прилики и разлики между „Синята китара“ от Банвил и „Изобретяване на самотата“ от Пол Остър: и двете са скорошни книги на големи писатели, кандидати за „Нобел“; и двете са чудно преведени от Иглика Василева. Но ако Банвил отделя високата литература и криминалния роман в две различни литературни персони, Остър предпочита да играе с пресечните точки между тях.
В „Град от стъкло“ например главният герой е автор на криминалета (загърбил „собствено литературното“ преди години), който пише под псевдоним, с когото се идентифицира по-малко, отколкото с героя си детектив; междувременно обаче го търсят именно като детектив на име… Пол Остър. Приема задачата, не се справя много и в пристъп на отчаяние намира „самия“ Пол Остър, за да го помоли за помощ. За капак авторът играе с границата между реално и фикционално, като дава на огледалния си образ в романа жена и син със същите имена като на своите собствени. И това е само началото на множество преплитания между героите в романите му… и елементи от собствената му биография.
Едва ли можем да се учудваме тогава, че когато в „Изобретяване на самотата“ започва да говори директно за баща си, читателят се чувства леко неловко от навлизането в интимното; неловко и недоверчиво. Остър (тъй де, гласът, който разказва и назовава себе си „Остър“) говори за опита да разгадае баща си след неговата смърт. Онова, което помни от него – непроницаем, отчужден човек, чието внимание така и не успява да изпроси, – постепенно се оказва невярно, по-скоро реакция на обидено момче, отколкото същността на човека. Парчета неизвестни досега факти променят издълбоко картината – спомняме си думите на Куин, че в криминалния жанр читателят е принуден да гледа на всеки детайл като на потенциално важен, способен да преобърне сюжета. Ето така става и тук. Покрай новото знание постепенно изплуват и други детайли, образът на бащата се стопля, макар и никога да не се избистря. Защото такава е природата на паметта. Казах ли, че „Синята китара“ също завършва с мисъл за бащата на героя?
Втората част на „Изобретяване на самотата“ се казва „Книга на паметта“. Няма вече „аз“, има „той“ – разказвачът говори за себе си в трето лице, сякаш е стигнал до някаква непоносима интимност и трябва да я отдели.
Поставя празен лист пред себе си и изписва тези думи с писалката. Беше. Никога няма да бъде отново.
Кое? Баща му? Миналото? Настоящето? Може би всичко заедно. Разказът се търкулва между пространства, обитавани в самота. Търбухът на кита. Островът на Робинзон. Старата му работна стая в Ню Йорк. Таванската стая на бащата на М. в Париж – там се укривал от нацистите. Стаята на Ане Франк.
Паметта като стая, като тяло, като череп, като череп, в който се помества стаята, в която седи тялото.
Стаята от прочутата картина на Ван Гог – наистина не бях забелязала, че леглото затиска вратата, пред другата е поставен стол, капаците на прозорците са хлопнати. Кулата на Хьолдерлин, в която поетът живее след полудяването си. Кула, построена от някой си Zimmer – „стая“ на немски. Защо паметта изисква самота, изисква изолация? Може би за да се изолира от бъдещето, което я разрушава. Така, както скърбящият негодува срещу смяната на сезоните. Но, казва Остър, освен това паметта е глас – и когато замълчи, той я чака да проговори отново.
Може да се питаме кой е разказвачът в тази втора част. Може да се объркваме от героите, почти всичките белязани с по един инициал. Може да се чудим на разсъжденията, с които обраства един мемоар. И какво общо имат с баща му. Ето това: Остър скърби за баща си, но и за невъзможността да го познава. За невъзможността да познаваш наистина друг човек. За затворената стая на черепа. И единственият начин да излезеш от нея е с глава надолу в мастилницата – също като Пинокио, гмуркащ се в мастиления мрак в търбуха на морския звяр. Преди наистина да започне да спасява баща си.
илюстрации Александра Георгиева, София: изд. „Алос“, 2021
Стихотворенията на Марий Росен изглеждат наистина като трохи – малки, състоящи се в повечето случаи от едно-единствено хрумване, най-често образ или смислов обрат. Трохите обаче имат свойството да се слепват; нервните пръсти да ги омачкат в топче хляб, което внезапно и почти неволно придобива черти.
Така е и тук: виждаме границата между вътрешното и външното пространство, „стаята череп“ и света – домът е пуст и празен, вътрешният глас кънти. С отместването на стените пустинята нараства. Какъв уютен дом е бягството!
Или пък да видим как се слепват трохите, свързани с натрупването на годините – детето не пораства, растат само играчките му; в един момент обаче явно е пораснало дотолкова, че носи камъка на Сизиф в джоба си; но всеки камък носи името Сизиф, тоест човекът носи себе си и цялото търкаляне наобратно; и ето, търколил се към детския си ръст, старецът облича някогашните си дрехи. Бутам планината, местя само себе си. Накъде я бутам впрочем? Върхът е на дъното. Вървя нагоре, потъвайки.
Може би в подобна кратка форма читателят би очаквал повече афоризъм, повече виц. Или най-малкото повече образи арабески. Слава богу, тези стихотворения като че ли не се интересуват от подобни очаквания – изглеждат повече търсещи искреността, отколкото искрата на ефекта.
Запазвам си едно, което прилича почти на коан:
ръката която протягам
все някой ден ме докосва
Post Syndicated from Bo Xiong original https://aws.amazon.com/blogs/devops/a-new-spark-plugin-for-cpu-and-memory-profiling/
Have you ever wondered if there are low-hanging optimization opportunities to improve the performance of a Spark app? Profiling can help you gain visibility regarding the runtime characteristics of the Spark app to identify its bottlenecks and inefficiencies. We’re excited to announce the release of a new Spark plugin that enables profiling for JVM based Spark apps via Amazon CodeGuru. The plugin is open sourced on GitHub and published to Maven.
This post shows how you can onboard this plugin with two steps in under 10 minutes.
Your app is built against Spark 3 and run on Amazon EMR release 6.x or newer. It doesn’t matter if you’re using Amazon EMR on Amazon Elastic Compute Cloud (Amazon EC2) or on Amazon Elastic Kubernetes Service (Amazon EKS).
For the purposes of illustration, consider the following example where profiling results are collected by the plugin and emitted to the “CodeGuru-Spark-Demo” profiling group.
spark-submit \
--master yarn \
--deploy-mode cluster \
--class \
--packages software.amazon.profiler:codeguru-profiler-for-spark:1.0 \
--conf spark.plugins=software.amazon.profiler.AmazonProfilerPlugin \
--conf spark.executorEnv.PROFILING_CONTEXT="{\\\"profilingGroupName\\\":\\\"CodeGuru-Spark-Demo\\\"}" \
--conf spark.executorEnv.ENABLE_AMAZON_PROFILER=true \
--conf spark.dynamicAllocation.enabled=false \tAn alternative way to specify PROFILING_CONTEXT and ENABLE_AMAZON_PROFILER is under the yarn-env.export classification for instance groups in the Amazon EMR web console. Note that PROFILING_CONTEXT, if configured in the web console, must escape all of the commas on top of what’s for the above spark-submit command.
[
{
"classification": "yarn-env",
"properties": {},
"configurations": [
{
"classification": "export",
"properties": {
"ENABLE_AMAZON_PROFILER": "true",
"PROFILING_CONTEXT": "{\\\"profilingGroupName\\\":\\\"CodeGuru-Spark-Demo\\\"\\,\\\"driverEnabled\\\":\\\"true\\\"}"
},
"configurations": []
}
]
}
]Once the job above is launched on Amazon EMR, profiling results should show up in your CodeGuru web console in about 10 minutes, similar to the following screenshot. Internally, it has helped us identify issues, such as thread contentions (revealed by the BLOCKED state in the latency flame graph), and unnecessarily create AWS Java clients (revealed by the CPU Hotspots view).
To help with troubleshooting, use a sample Spark app provided in the plugin to check if everything is set up correctly. Note that the profilingGroupName value specified in PROFILING_CONTEXT should match what’s created in CodeGuru.
spark-submit \
--master yarn \
--deploy-mode cluster \
--class software.amazon.profiler.SampleSparkApp \
--packages software.amazon.profiler:codeguru-profiler-for-spark:1.0 \
--conf spark.plugins=software.amazon.profiler.AmazonProfilerPlugin \
--conf spark.executorEnv.PROFILING_CONTEXT="{\\\"profilingGroupName\\\":\\\"CodeGuru-Spark-Demo\\\"}" \
--conf spark.executorEnv.ENABLE_AMAZON_PROFILER=true \
--conf spark.yarn.appMasterEnv.PROFILING_CONTEXT="{\\\"profilingGroupName\\\":\\\"CodeGuru-Spark-Demo\\\",\\\"driverEnabled\\\":\\\"true\\\"}" \
--conf spark.yarn.appMasterEnv.ENABLE_AMAZON_PROFILER=true \
--conf spark.dynamicAllocation.enabled=false \
/usr/lib/hadoop-yarn/hadoop-yarn-server-tests.jarRunning the command above from the master node of your EMR cluster should produce logs similar to the following:
21/11/21 21:27:21 INFO Profiler: Starting the profiler : ProfilerParameters{profilingGroupName='CodeGuru-Spark-Demo', threadSupport=BasicThreadSupport (default), excludedThreads=[Signal Dispatcher, Attach Listener], shouldProfile=true, integrationMode='', memoryUsageLimit=104857600, heapSummaryEnabled=true, stackDepthLimit=1000, samplingInterval=PT1S, reportingInterval=PT5M, addProfilerOverheadAsSamples=true, minimumTimeForReporting=PT1M, dontReportIfSampledLessThanTimes=1}
21/11/21 21:27:21 INFO ProfilingCommandExecutor: Profiling scheduled, sampling rate is PT1S
...
21/11/21 21:27:23 INFO ProfilingCommand: New agent configuration received : AgentConfiguration(AgentParameters={MaxStackDepth=1000, MinimumTimeForReportingInMilliseconds=60000, SamplingIntervalInMilliseconds=1000, MemoryUsageLimitPercent=10, ReportingIntervalInMilliseconds=300000}, PeriodInSeconds=300, ShouldProfile=true)
21/11/21 21:32:23 INFO ProfilingCommand: Attempting to report profile data: start=2021-11-21T21:27:23.227Z end=2021-11-21T21:32:22.765Z force=false memoryRefresh=false numberOfTimesSampled=300
21/11/21 21:32:23 INFO javaClass: [HeapSummary] Processed 20 events.
21/11/21 21:32:24 INFO ProfilingCommand: Successfully reported profileNote that the CodeGuru Profiler agent uses a reporting interval of five minutes. Therefore, any executor process shorter than five minutes won’t be reflected by the profiling result. If the right profiling group is not specified, or it’s associated with a wrong EC2 role in CodeGuru, then the log will show a message similar to “CodeGuruProfilerSDKClient: Exception while calling agent orchestration” along with a stack trace including a 403 status code. To rule out any network issues (e.g., your EMR job running in a VPC without an outbound gateway or a misconfigured outbound security group), then you can remote into an EMR host and ping the CodeGuru endpoint in your Region (e.g., ping codeguru-profiler.us-east-1.amazonaws.com).
To avoid incurring future charges, you can delete the profiling group configured in CodeGuru and/or set the ENABLE_AMAZON_PROFILER environment variable to false.
In this post, we describe how to onboard this plugin with two steps. Consider to give it a try for your Spark app? You can find the Maven artifacts here. If you have feature requests, bug reports, feedback of any kind, or would like to contribute, please head over to the GitHub repository.
Author:
Post Syndicated from Elise Chahine original https://aws.amazon.com/blogs/architecture/author-spotlight-seth-eliot-principal-reliability-solutions-architect-at-aws/
The Author Spotlight series pulls back the curtain on some of AWS’s most prolific authors. Read on to find out more about our very own Seth Eliot’s journey, in his own words!
At Amazon Web Services (AWS) and Amazon, we talk about “super powers” a lot. Everyone has them! I’ve discovered that mine is to take technical topics and make them actionable for builders and internal/external stakeholders at all levels.
As Principal Reliability Solutions Architect for AWS Well-Architected, I work with customers on topics such as disaster recovery, assessing resilience, and chaos engineering. What I really enjoyabout this role is how much I learn every day. Customers always have new challenges, and I love finding new solutions for them. At events like AWS Global Summits or AWS re:Invent, I enjoy interacting with customers, such as when I run Chalk Talks, where I answer questions from the audience about reliability in the cloud.
Prior to joining AWS, I was a Solutions Architect for one of AWS’s biggest customers—Amazon.com! I traveled around the world to work hands-on with Amazon developers in places like Japan and Luxembourg to help modernize their workloads on AWS and get the most out of AWS technologies, like serverless and containers. Meeting face-to-face with folks and helping them use these technologies was really rewarding and very educational.
I’ve also worked as a Principal Engineer with Amazon Fresh grocery delivery and Amazon International Technology. These were two very different areas to work in, but they both have development teams all over the world that I was honored to help with their software design, agile development, and career guidance. By now, you’re likely noticing a pattern in my career…?
If you go back a bit further, I spent about 5 years working “across the lake” from Amazon HQ in Seattle, Washington, at Microsoft in Redmond during a really interesting moment in their history: moving, culturally and technically, from a “box product” company to one that creates software services. I am proud to have played a role in that move!
I am a “boomerang,” meaning that I actually was with Amazon prior to my time with Microsoft, and I came back. During my first stint here, I worked on the original team that launched what would become Prime Video. Back then, it was download-only experience (not streaming) and called “Amazon Unbox.” From where I sit now, it is amazing to see how the product has evolved.
Throughout these experiences, the thing that keeps me going is the opportunity to help builders and stakeholders to solve their hard problems. There is nothing more satisfying than after meeting with a person or team, getting feedback from them that I was able to help them.
My first AWS blog post! The real work was updating the AWS Well-Architected Reliability Pillar itself. I enjoyed collaborating with many smart experts across AWS to harness their diverse perspectives in the pillar update. Enjoy the read!
I was really excited by the release of AWS Resilience Hub (and was honored to be part of developing it). Finally, many of the best practices I talk about with customers are now automatically assessed against your workload with recommendations.
