Post Syndicated from Patrick Kennedy original https://www.servethehome.com/this-is-an-intel-xeon-6-soc-dpu-on-a-pcie-card-from-senao-at-computex-2026/
We saw an Intel Xeon 6 SoC-based next-generation SmartNIC DPU at Computex 2026. This Senao SX906 is really neat
The post This is an Intel Xeon 6 SoC DPU on a PCIe Card from Senao at Computex 2026 appeared first on ServeTheHome.
Post Syndicated from Spencer McIntyre original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-13-06-2026
As hard as we try to ensure that Metasploit is bug free, issues inevitably come up. Whether you’re running a module on an op or writing a new one, what we can do is make the debugging experience easier. To that end one of our two Google Summer of Code (GSoC) projects is here to deliver. Building on the previous pattern of HttpTrace comes two new options KerberosTicketTrace and CertificateTrace. These options, when enabled, will enable debugging output of Kerberos tickets and Certificates that are both sent and received by applicable modules. Now when things aren’t going quite right, users have new levers to reach for to inspect what’s happening under the hood.
For example, to inspect exactly what’s happening when using the auxiliary/admin/kerberos/get_ticket module:
msf auxiliary(admin/kerberos/get_ticket) > set KerberosTicketTrace true KerberosTicketTrace => true msf auxiliary(admin/kerberos/get_ticket) > run [*] Running module against 192.168.159.10 [*] 192.168.159.10:88 - Getting TGT for [email protected] #################### # Kerberos Request: AS-REQ #################### Protocol Version: 5 Message Type: 10 (AS-REQ) Pre-Authentication Data: Entry[0]: Type: 128 (PA_PAC_REQUEST) Value: [binary 7 bytes: 3005a0030101ff] Request Body: KDC Options: Value: 1082195984 Flags: - FORWARDABLE - RENEWABLE - CANONICALIZE - RENEWABLE_OK Client Name: Name Type: 1 (NT_PRINCIPAL) Name String: - smcintyre Realm: MSFLAB.LOCAL Server Name: Name Type: 1 (NT_PRINCIPAL) Name String: - krbtgt - MSFLAB.LOCAL Till: 2026-06-12T18:21:36Z Rtime: 2026-06-12T18:21:36Z Nonce: 6831592 Encryption Type: - 18 (AES256) - 17 (AES128) - 23 (RC4_HMAC) - 3 (DES_CBC_MD5) - 16 (DES3_CBC_SHA1) #################### # Kerberos Response: KRB-ERROR #################### Protocol Version: 5 Message Type: 30 (KRB-ERROR) Server Time: 2026-06-11T18:21:36Z Server Microseconds: 862696 Error Code: Name: KDC_ERR_PREAUTH_REQUIRED Value: 25 Description: Additional pre-authentication required Realm: MSFLAB.LOCAL Server Name: Name Type: 1 (NT_PRINCIPAL) Name String: - krbtgt - MSFLAB.LOCAL Error Data: [binary 87 bytes: 30553032a103020113a22b04293027301ea003020112a1171b154d53464c41422e4c4f43414c736d63696e747972653005a0030201173009a103020102a20204003009a103020110a20204003009a10302010fa2020400] #################### # Kerberos Request: AS-REQ #################### Protocol Version: 5 Message Type: 10 (AS-REQ) Pre-Authentication Data: Entry[0]: Type: 2 (PA_ENC_TIMESTAMP) Value: [binary 67 bytes: 3041a003020112a23a0438724f4965bd3deb1f061e807b616a09b613f59d9a6749eaee895e2ec3ed3045403cb28874acaa371681e3957a3ec23879141411ba788886f3] Entry[1]: Type: 128 (PA_PAC_REQUEST) Value: [binary 7 bytes: 3005a0030101ff] Request Body: KDC Options: 1350565888 Client Name: Name Type: 1 (NT_PRINCIPAL) Name String: - smcintyre Realm: MSFLAB.LOCAL Server Name: Name Type: 1 (NT_PRINCIPAL) Name String: - krbtgt - MSFLAB.LOCAL Till: 2026-06-12T18:21:36Z Rtime: 2026-06-12T18:21:36Z Nonce: 7068778 Encryption Type: - 18 (AES256) - 23 (RC4_HMAC) #################### # Kerberos Response: AS-REP #################### Protocol Version: 5 Message Type: 11 (AS-REP) Pre-Authentication Data: Entry[0]: Type: 19 (PA_ETYPE_INFO2) Value: [binary 34 bytes: 3020301ea003020112a1171b154d53464c41422e4c4f43414c736d63696e74797265] Client Realm: MSFLAB.LOCAL Client Name: Name Type: 1 (NT_PRINCIPAL) Name String: - smcintyre Ticket: Ticket Version Number: 5 Realm: MSFLAB.LOCAL Server Name: Name Type: 1 (NT_PRINCIPAL) Name String: - krbtgt - MSFLAB.LOCAL Encrypted Part: Encryption Type: 18 (AES256) Key Version Number: 2 Cipher: [binary 1098 bytes: a3b825bd279344fd0bc454654f7906e31c8f4918c7c69319515e6a722515b55da36e2ae26f107d9f6278b029ba4c1b937a8a4e9df04f4a54da43794b2216fd5d7762582e94e3aa72fd14bfa0cfb9ff5c9a138acecd57351ff7ca98a9d7d890445316b04359e9210f93ba72c578a1605fb5502ba00fe67d9b55417e356e6400ef3bd07b9e1a8e4aedeb62249bef9f56f0cda3a30969d33fe6999a4855ae8f666b82fdff29047b14d4bcd77b31a6b9ce1ee3a4425cd197250af0cc878995afbeb4de42fb7e55d6095ab27ab3fa7f0afb0010b8e8f5e721a3d0417c7342df77619f6520e726652dc4417d2dbc044529236557441f87a50a7188242fb177e5f1bd45d31902c877d51cd05af7215e520c410e9b7036bc78c1ddad458b0ad99832c4fdd6f8f523ca4241aee8ebce4a0000202ebfb870761833feffc2c248683751a11d556bba4c59b20c7a1627b187d4d4679e19b1928f3ab7edeef3f01b459324178a9e49976519b58d6d7164b29c77e20625c4e710e3bbb0bb32452d4bdb9ed0c3e9873b9511cadf36fb0b372af5f67310319f160c0242d2fff1095bc467c4eb6da0382ab0587d519e5390e56eacb6db4f98c2c25b7ac22edf40db2e0e0eca03dfeba48327916a8caa85c382d04dcea16116c76132dcbfc168b7e3435a37f812f479f1e8309b124a9dcbac1e2ae83063a5e49c1ea584f13f64832c713577f07b3229e83c0fe73c3dc350640a69ea643ef24b66ed17114c262d3e5cdddb8182d8da49173e597b23d94f8ef652433713bf1d5e91c7f984945940d27755584137b00baa9696cdd121c641870830ffc86c8f9989254b6b804912c4989014b3f849cd02e6b06d3cc6401fd3f830cfcd36a0ecf31309d5b6dc82a65b427818694002bcf5fac9c936e1d64205a397126f39f684903803a5405baff041881339c4c8d325a2f446178b66383c209f3dba61bdda626f6e6d63c473638191e447d58aebfcb5a98104c2f96afa3283ac3aca675937afd7c497f1bd41a3dd1b52a6a16db791421a4ab9189d9fa0d610713d9c1eeb2f9c46d6ea197f48e2e643fe773ece0855c63b44b6020044fb7cc1396b26b4747941484b73108b7c1c90e2670cf723033274cc24ceb66a7054b35a9653cd7391a4f81b2c977ee251c9295e47be46b14c66b4031c6758415e543153bde190af0f1abe0f207d84145e3521850f89765997ab72cccaaeb4c5ce8b8be9b33712090d59424c2517e4cd539740750f5792f171fec2b4e4b4bc00cb77bc308abe1b70c75684734aa9ef03c4b419d2e10b4ea6229faf5a4b2af9483156ea32bc4b298f158067ac45afd5c812c407bda57880434cb93a60ac19799004a9adc72d845401ebb8e2a31ed0edf539233d293b1141bb49b36b6475d87c0fd114d97a946e82e39ed58e6c2e0d72826059600d412bd05aaf0af5602ade2f1ff6db363ec33e25756c4bc417b248344ba19ecd8d80d2cd2c2ff32aa355c22ee96166fc7043204dcc48b5595416c4312855c7d6e31d422c93c1d6f3df1a5890b45fc55f1b757b8e] Encrypted Part: Encryption Type: 18 (AES256) Key Version Number: 3 Cipher: [binary 271 bytes: 357637faf370a69ec4780f1fc4308e3d639e59ebbdb5d208cf6df75470bcefdd5210a098aa716055f758d9ec58674abc4b56cec2923329309e2be192db3ee1a63c6f0133a96c440707a0f29f2e075f90c54e2ab7626132f8e898112f81cbde6905d992d9ec6a4c26087043ea8f97c1a876354c47b4a6a76e3321f42edc483530d5248f8daa01db15ab019ac4179dfdb5f6d6c1f2666b9983cd02989612acdad2b2efe352fb9708a080fd304d17a87ff1e152dc8ca981de6cff418f38c5c28612766bfc13fbac51bad1a01fcd7aae544c7d839124e1bce745d20d06c8aca5c7125afe069e8d5299a10cd27b392bd8ae3893181f132f3d49dd746c6c70c6d2b651df998c59be84f2d5b83e5b3c0a71b2] [+] 192.168.159.10:88 - Received a valid TGT-Response [*] 192.168.159.10:88 - TGT MIT Credential Cache ticket saved to /home/smcintyre/.msf4/loot/20260611142136_default_192.168.159.10_mit.kerberos.cca_918073.bin #################### # Kerberos Credential: TGT #################### Creds: 1 Credential[0]: Server: krbtgt/[email protected] Client: [email protected] Ticket etype: 18 (AES256) Key: 58b969939485b53dee75e4399253524d132cc2ca145f4da4e4951c04a843e544 Subkey: false Ticket Length: 1188 Ticket Flags: 0x50e10000 (FORWARDABLE, PROXIABLE, RENEWABLE, INITIAL, PRE_AUTHENT, CANONICALIZE) Addresses: 0 Authdatas: 0 Times: Auth time: 2026-06-11 14:21:36 -0400 Start time: 2026-06-11 14:21:36 -0400 End time: 2026-06-12 00:21:36 -0400 Renew Till: 2026-06-12 14:21:36 -0400 Ticket: Ticket Version Number: 5 Realm: MSFLAB.LOCAL Server Name: krbtgt/MSFLAB.LOCAL Encrypted Ticket Part: Ticket etype: 18 (AES256) Key Version Number: 2 Cipher: o7glvSeTRP0LxFRlT3kG4xyPSRjHxpMZUV5qciUVtV2jbiribxB9n2J4sCm6TBuTeopOnfBPSlTaQ3lLIhb9XXdiWC6U46py/RS/oM+5/1yaE4rOzVc1H/fKmKnX2JBEUxawQ1npIQ+TunLFeKFgX7VQK6AP5n2bVUF+NW5kAO870HueGo5K7etiJJvvn1bwzaOjCWnTP+aZmkhVro9ma4L9/ykEexTUvNd7Maa5zh7jpEJc0ZclCvDMh4mVr7603kL7flXWCVqyerP6fwr7ABC46PXnIaPQQXxzQt93YZ9lIOcmZS3EQX0tvARFKSNlV0Qfh6UKcYgkL7F35fG9RdMZAsh31RzQWvchXlIMQQ6bcDa8eMHdrUWLCtmYMsT91vj1I8pCQa7o685KAAAgLr+4cHYYM/7/wsJIaDdRoR1Va7pMWbIMehYnsYfU1GeeGbGSjzq37e7z8BtFkyQXip5Jl2UZtY1tcWSynHfiBiXE5xDju7C7MkUtS9ue0MPphzuVEcrfNvsLNyr19nMQMZ8WDAJC0v/xCVvEZ8TrbaA4KrBYfVGeU5Dlbqy220+YwsJbesIu30DbLg4OygPf66SDJ5FqjKqFw4LQTc6hYRbHYTLcv8Fot+NDWjf4EvR58egwmxJKncusHiroMGOl5JwepYTxP2SDLHE1d/B7MinoPA/nPD3DUGQKaepkPvJLZu0XEUwmLT5c3duBgtjaSRc+WXsj2U+O9lJDNxO/HV6Rx/mElFlA0ndVWEE3sAuqlpbN0SHGQYcIMP/IbI+ZiSVLa4BJEsSYkBSz+EnNAuawbTzGQB/T+DDPzTag7PMTCdW23IKmW0J4GGlAArz1+snJNuHWQgWjlxJvOfaEkDgDpUBbr/BBiBM5xMjTJaL0RheLZjg8IJ89umG92mJvbm1jxHNjgZHkR9WK6/y1qYEEwvlq+jKDrDrKZ1k3r9fEl/G9QaPdG1KmoW23kUIaSrkYnZ+g1hBxPZwe6y+cRtbqGX9I4uZD/nc+zghVxjtEtgIARPt8wTlrJrR0eUFIS3MQi3wckOJnDPcjAzJ0zCTOtmpwVLNallPNc5Gk+Bssl37iUckpXke+RrFMZrQDHGdYQV5UMVO94ZCvDxq+DyB9hBReNSGFD4l2WZercszKrrTFzouL6bM3EgkNWUJMJRfkzVOXQHUPV5Lxcf7CtOS0vADLd7wwir4bcMdWhHNKqe8DxLQZ0uELTqYin69aSyr5SDFW6jK8SymPFYBnrEWv1cgSxAe9pXiAQ0y5OmCsGXmQBKmtxy2EVAHruOKjHtDt9TkjPSk7EUG7SbNrZHXYfA/RFNl6lG6C457VjmwuDXKCYFlgDUEr0FqvCvVgKt4vH/bbNj7DPiV1bEvEF7JINEuhns2NgNLNLC/zKqNVwi7pYWb8cEMgTcxItVlUFsQxKFXH1uMdQiyTwdbz3xpYkLRfxV8bdXuO [*] Auxiliary module execution completed msf auxiliary(admin/kerberos/get_ticket) >
Stay tuned for future enhancements like KerberosTicketTraceLevel which should have verbosity toggles such as meta, ticket, and full. We’d like to thank our GSoC contributors eve0805 and Pushpenderrathore for their hard work on this project.
Metasploit is currently reconsidering the UX of evasion modules whereby users are currently required to use the module, set the payload, run it, then return to their exploit and copy the generated output from the evasion module into the exploit. This is a cumbersome process and we think we can do better but before we commit to a direction, we are soliciting feedback from the community on what they think would be the best path forward. To that end, we’ve published a writeup of the options we’re considering and a form through which we’re hoping to receive feedback. The form contains 3 questions and will be open until July 1st, 2026.
Authors: boredchilada and h00die
Type: Exploit
Pull request: #21212 contributed by h00die
Path: multi/misc/clickfix_server
Description: Adds a new Metasploit exploit module exploit/multi/misc/clickfix_server that runs an HTTP server to deliver a “ClickFix”-style social-engineering page which copies a generated command payload to the victim’s clipboard that they are prompted execute.
You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.
As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:
If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/WM97hgDwOK4
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/friday-squid-blogging-squid-inspired-fluid-pump.html
This fluid pump was inspired by the way squids propel themselves through the water.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Post Syndicated from jake original https://lwn.net/Articles/1077052/
In a shortened session in the filesystem track at the 2026 Linux Storage,
Filesystem, Memory Management, and BPF Summit, Amir Goldstein gave an
update on the overlayfs
union filesystem. There are some new features over the last few years
that he wanted to mention, along with looking at the status of nesting
overlayfs layers. The composefs use case
that was discussed at the summit in 2023
has led to some interesting changes to overlayfs.
Post Syndicated from Aarthi Srinivasan original https://aws.amazon.com/blogs/big-data/access-amazon-s3-data-files-directly-using-aws-lake-formation-permissions/
Data scientists and ML engineers often need to access raw data files in Amazon Simple Storage Service (Amazon S3) for machine learning training, data exploration, and generative AI workflows. However, when table-level access is governed by AWS Lake Formation, accessing the underlying S3 files has required maintaining separate permission mechanisms. S3 bucket policies or AWS Identity and Access Management (IAM) role policies create operational overhead and risk of permission drift.
Lake Formation now supports direct access to S3 data file locations for tables whose permissions it manages. Previously, data scientists with Lake Formation permissions on AWS Glue Data Catalog tables could query them using spark.sql(). Now, they can also read and write the underlying S3 data files using spark.read.parquet() or spark.read.csv() from Amazon EMR Spark jobs, Amazon SageMaker Unified Studio notebooks with EMR compute, and custom applications. All access is governed by the same Lake Formation permissions.
This capability is powered by the new GetTemporaryDataLocationCredentials() API, which vends temporary credentials scoped to registered S3 locations when callers have appropriate Lake Formation permissions on the corresponding Data Catalog tables. This eliminates the need to manage separate S3 bucket policies for file-level access while maintaining fine-grained access control in Lake Formation for table-based access. It enables your data scientists to explore S3 datasets securely, accelerate machine learning pipelines, and build generative AI workflows without compromising governance.
In this post, we demonstrate reading from and writing to Lake Formation-managed S3 locations using Apache Spark jobs from EMR. Lake Formation credential vending for S3 location access is available in EMR release label 7.13 and later, Boto3 1.42.29 and later, AWS Java SDK 2.41.32 and later, and AWS Command Line Interface (AWS CLI) version 2.33.1 and later.
“Through our close collaboration with AWS, Lake Formation’s new S3 location-based permissions have transformed how we manage data governance at Intuit. By unifying two separate access mechanisms for the same data into one unified permission model, we’ve dramatically reduced complexity and streamlined our auditing process. This is exactly the kind of simplification that lets our teams move faster without compromising security, ensuring we maintain the strict compliance and governance standards our regulators expect.”
— Tapan Upadhyay, Group Engineering Manager, Intuit
Lake Formation has made available a specialized library AWS Lake Formation Credential Vending Plugin for AWS SDK V2 for Java. The Java plugin intercepts S3 requests for data, checks Lake Formation permissions for the requested location, and provides temporary scoped credentials to the client if permissions are granted in Lake Formation. If the S3 location access permissions are not managed by Lake Formation, the plugin checks for access in Amazon S3 Access Grants and lastly falls back to IAM permissions. The plugin is supported independently of Spark and comes as an enhancement to EMR Spark Full Table Access (FTA) mode, starting in EMR 7.13 and later. The plugin is integrated at the S3A level. Therefore, any client of S3A can enable it by setting the S3A configurations, in addition to the EMR Lake Formation Full Table Access (FTA) configuration as follows:
With the Java plugin, you can enable governance for data lake resources in your custom applications with Lake Formation permissions – managing both fine grained access for users requiring restricted access on Data Catalog tables while providing direct S3 object level access to use-cases that require them.
Note: (1) The principal that will be accessing direct S3 locations of the tables will require full table access. That is, Lake Formation SELECT permission on all columns and rows of the table is required. (2) The Spark cluster needs FTA configuration. (3) Currently, Apache Iceberg table format is not supported with this plugin.
A financial services company runs daily ETL jobs using Spark in EMR. They process raw transaction records in S3 and store the processed records in another S3 location. The transformed Parquet data is registered with Lake Formation and cataloged as a table in Data Catalog. The ETL job will have direct IAM access to the raw data location, while it uses Lake Formation permissions to write to and read from the curated table location. Downstream, a data-analyst role will query the curated table, with restricted column access. The solution is shown in Figure 1.
Figure 1 – Architecture shows EMR Spark writing curated records to the S3 location of a table using Lake Formation permissions while Data-Analyst queries the same table with Lake Formation fine grained access control in Athena.
To get started exploring this feature, we recommend you have the following setup.
First, we will get the setup ready with S3, sample database, table, and data. We will add a raw data set to S3 location, create a table with parquet data in another S3 location that represents the curated dataset for further downstream consumption. We will register the table data location with Lake Formation and grant permissions for the EMR run time role and Data-Analyst role.
Your S3 bucket will have the following structure.
Raw data – s3://<your-bucket-name>/raw/transactions/dt=2024-03-21/
Process data for table – s3://<your-bucket-name>/processed/transactions/
Spark script – s3://<your-bucket-name>/scripts/
Logs for the EMR cluster – s3://<your-bucket-name>/logs/
From the Athena console query editor, create a table in Data Catalog.
2.1 Register the table data location s3://<your-bucket-name>/processed/transactions/ with Lake Formation in Lake Formation mode using the custom S3 registration IAM role. For details on how to register locations with Lake Formation, refer Adding an Amazon S3 location to your data lake.
2.2 Grant DESCRIBE permission on the database finance_db and ALL permission on the table transactions_processed to your EMR runtime role.
2.3 Grant Data location permission to EMR runtime role on the curated table’s location. This is to allow writing to that location.
2.4 Grant DESCRIBE permission on the database finance_db and SELECT permission on the table transactions_processed to your Data-Analyst role. Exclude the columns transaction_id and account_number while granting SELECT permissions on the table to the Data-Analyst role.
For details on how to grant Lake Formation permissions, refer Granting database permissions using the named resource method; Granting table permissions using the named resource method and Granting data location permissions.
3.1 Download the script bdb-5860-script.py.
3.2 Edit the S3 bucket name placeholder in the script (RAW_PATH and TABLE_PATH) to your resource names and upload to your S3 path s3://<your-bucket-name>/scripts/.
3.3 Make sure your EMR runtime role has access to the script location in its IAM policy permissions.
3.4 Submit and run the script as a step to the EMR cluster, following instructions at Add a Spark step.
What does the script do?
It populates raw records of transaction data into a Spark data frame, writes to the raw data bucket location using IAM permissions on the EMR runtime role. We apply some transformations and write directly to the S3 location of the table that is registered with Lake Formation, from the data frame using Spark’s native Parquet writer.
The following figure shows the stdout of the step.
The Java plugin integrated into EMR 7.13 automatically handles the access for the table’s data location registered with Lake Formation, so you don’t need to manually call the GetTemporaryDataLocationCredentials() API. In this example, the table data location s3://<your-bucket-name>/processed/transactions/ is registered with Lake Formation, for which EMR runtime role is granted ALL permissions. The direct S3 location access support by Lake Formation allows reading and writing to the location directly using Spark data frame.
Log in as the Data-Analyst role to the Athena console. Run a select query on the table as follows.
The Data-Analyst role should see all but two columns of the table.
With these steps complete, we’ve read from and written to direct S3 locations using Spark data frames with the syntax s3://bucketname/prefix/, and accessed the same data using database_name.table_name syntax with Lake Formation permissions. This shows fine-grained access at table level and coarse-grained access at the file path level.
To avoid incurring costs, clean up the resources you created for this post.
In this post, we showed how to use Lake Formation’s direct S3 location access to read and write data files using Spark data frames from Amazon EMR, while maintaining unified governance through Lake Formation permissions. We walked through the GetTemporaryDataLocationCredentials() API and the AWS Lake Formation Credential Vending Plugin for AWS SDK v2 for Java, which is integrated into EMR release labels 7.13 and later.
This capability unifies permission management for both fine-grained table-based access and direct S3 file path access in Lake Formation. Your data scientists can now use spark.read.parquet() and spark.write alongside spark.sql(), governed by the same permissions, audited in the same CloudTrail logs, and managed from a single console.
To get started, launch an EMR 7.13 cluster and start exploring the feature. Here are some additional resources:
Acknowledgements: We would like to thank all the team members who worked to launch this feature successfully – Rajas Bhate, Akhil Yendluri, Kunal Parikh, Sharda Khubchandani, Dhananjay Badaya, Santhosh Padmanabhan, Nitin Agrawal and Sandeep Adwankar.
Post Syndicated from The Hook Up original https://www.youtube.com/watch?v=D_78hM_1buM
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=zbIyM3ce9TM
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/copernicus/
Преди време намерих данните на европейската обсерватория Copernicus, но така и не ми е оставало време да ги прегледам. Съдържат безценни данни за земеделската земя, горите, крайбрежните зони, рискове от наводнения и пожари. Тази седмица седнах да погледна един от слоевете – за изкуствено покрита земя. Разбирайте асфалт и бетон, който изцяло покрива кварталите ни.
В миналото съм критикувал доста прилагането на изискванията за озеленяване специално в София и ролята му в презастрояването. Докато един бивш главен архитект ги наричаше безсмислени, а доста строители – прекомерни, всъщност са далеч не достатъчно изискващи и отчасти трудни за прилагане. Не, че някой се е опитвал да ги наложи истински дори в сегашния им вид. На практика се позволява бетонирането на цели парцели стига строителят да може да покаже няколко кашпи с дървета и няколко квадрата чима с трева. В този смисъл вече избилата мухъл по стените се брои към озеленяването за целите на акт 16. Не защото нормативно е позволено, а защото има добре установена практика с ревностно пазена документация. Заради последното заведох тази седмица няколко дела.
Една от основните роли на изискванията за озеленяване е не само чистота на въздуха и намаляване на шумовото замърсяване, но и задържане на водата от проливните дъждове, за да не се получават наводнения и пропускането ѝ надолу, за да захранва подпочвените води. За съжаление, последните са под огромен риск не само, защото масово и често нелегално се използват за миене на коли в автомивки и сгради без право да се вържат към ВИК, но защото все по-голяма част от София е практически запечатана.
Виждаме го при всеки следващ строеж и това се позволява от ЗУТ и изискванията за озеленяване в София. Исках да разбера колко точно. Copernicus предоставя такива данни. Имат слоевете за 2018, 2021 и 2024-та. Следващото заснемане ще е догодина та ще може да сравним какво се е случило покрай бума на влезли в експлоатация имоти след многото разрешения за и започнати строежи преди това.
Интерактивна карта със слоевете може да видите на сайта на обсерваторията. Тук показвам изгледа през трите години. За съжаление, тази през 2018-та е направена по различен модел и не пасва на следващите. Вижда се ясно обаче как липсват сградите от източната страна на горния край на Самоковско шосе, в Манастирски ливади, на север от централна гара и на юг от Бизнес парка. В последната снимка показвам сравнението между 2021-ва и 2024-та. В червено се виждат новите „запечатани“ части на София. Това не означава, че не се е строяло другаде преди това, а че там вече е имало ниски сгради, производства и друго, макар и далеч не с такава интензивност на застрояване.
Може сменяте галерията със стрелката надясно или да ги видите и тук на цял екран: 2018, 2021, 2024, промяна при 2024.
Тепърва ще разглеждам данните на Copernicus. Има интересни показатели за озеленяването.
Post Syndicated from Jonah Burgess original https://www.rapid7.com/blog/post/etr-active-exploitation-of-oracle-peoplesoft-zero-day-cve-2026-35273
On June 10, 2026, Oracle published a security alert for CVE-2026-35273, a critical vulnerability in the Updates Environment Management component of PeopleSoft Enterprise PeopleTools. Oracle released an out-of-band patch the same day as the advisory, underscoring the urgency of remediation. The vulnerability has a CVSSv3.1 score of 9.8 and is remotely exploitable without authentication. Per the vendor advisory, successful exploitation may result in remote code execution (RCE). TrendAI has classified the underlying flaw as a server-side request forgery (CWE-918). PeopleTools versions 8.61 and 8.62 are affected.
CVE-2026-35273 was reported to Oracle through TrendAI’s Zero Day Initiative. According to a report published by Mandiant on June 11, 2026, this vulnerability has been exploited in the wild as a zero-day prior to the vendor security alert, with active exploitation observed between May 27 and June 9, 2026, predating Oracle’s advisory by two weeks.
Mandiant has attributed the campaign to UNC6240 (ShinyHunters), a financially motivated cybercriminal collective known for data theft and extortion. ShinyHunters has been linked to breaches across cloud services, SaaS platforms, and telecommunications providers, frequently exploiting weak authentication controls, stolen credentials, and cloud misconfigurations rather than deploying sophisticated malware.
Based on information published by Mandiant, the campaign heavily targeted the higher education sector; 68 percent of the more than 100 notified organizations were universities and colleges. The observed exploitation targeted PeopleSoft’s Environment Management Hub (PSEMHUB) endpoints, and data stolen during the campaign was published on the ShinyHunters Data Leak Site (DLS) on June 9, 2026.
The /PSIGW/HttpListeningConnector URI path appears in both the indicators of compromise for this campaign and in a PeopleSoft exploit chain for CVE-2013-3821, detailed by Lexfo in 2017. A related XML External Entity (XXE) vulnerability, CVE-2017-3548, targeted a different Integration Gateway connector (PeopleSoftServiceListeningConnector) under the same /PSIGW/ path.
TrendAI’s detection signatures for CVE-2026-35273 classify the underlying vulnerability as an SSRF. These include IPS Rule 1012580 (“Oracle Peoplesoft PeopleTools SSRF Vulnerability”) and DDI Rule 5855 (“Peoplesoft PeopleTools Environment Management Hub (PSEMHUB) SSRF Exploit”). Mandiant describes CVE-2026-35273 as a critical remote code execution vulnerability, indicating that the SSRF serves as the mechanism through which code execution is achieved. Based on Mandiant’s analysis, two endpoints are involved in exploitation: /PSEMHUB/hub and /PSIGW/HttpListeningConnector. The exploit chain may also cause the target system to make outbound SMB connections (TCP port 445) to external destinations, potentially allowing attackers to capture Windows machine-account NetNTLM hashes.
Post-exploitation activity observed by Mandiant included the deployment of MeshCentral (an open-source, and self-hosted web-based remote monitoring and management platform) remote management agents configured to masquerade as Microsoft Azure services (e.g., meshagent64-azure-ops.exe), with C2 communications directed to wss://azurenetfiles[.]net:443/agent.ashx. The attackers performed internal reconnaissance of PeopleSoft configurations, deployed lateral movement scripts, and exfiltrated data using zstd compression.
Organizations running PeopleTools versions 8.61 or 8.62 should apply the vendor-supplied patch on an emergency basis, without waiting for a regular patch cycle to occur. Oracle has characterized this as a high-priority risk reduction measure.
In addition to patching, organizations should implement the following compensating controls:
Disable the Environment Management Hub (EMHub) Service in multi-server configurations, or completely remove the PSEMHUB application in single-server configurations.
Block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector at the network perimeter or firewall level. Per Mandiant, restricting these endpoints is considered non-breaking for standard end-user PeopleSoft Internet Architecture (PIA) browser sessions.
Monitor outbound SMB traffic (TCP port 445) from PeopleSoft servers to untrusted external destinations.
Given that exploitation occurred as early as May 27, 2026, Rapid7 strongly recommends investigating for signs of compromise even after patching, using the indicators of compromise outlined below.
For the latest mitigation guidance, please refer to the Oracle security alert and Mandiant’s report.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-35273 with authenticated vulnerability checks available in the 12th June 2026 content release.
Customers leveraging Rapid7’s Intelligence Hub can track the latest developments surrounding CVE-2026-35273, including indicators of compromise (IOCs) from the Mandiant report published on June 11, 2026.
The following indicators of compromise are sourced from Mandiant’s report. Mandiant has also published a GTI collection with additional IOCs for registered users.
Staging and C2 infrastructure:
142.11.200[.]186
142.11.200[.]187
142.11.200[.]188
142.11.200[.]189
142.11.200[.]190
azurenetfiles[.]net (C2 domain masquerading as Microsoft Azure)
176.120.22[.]24 (ShinyHunters DLS mirror)
|
Filename |
Description |
SHA-256 |
|---|---|---|
|
meshagent64-azure-ops.exe |
Pre-configured Windows MeshCentral agent |
f02a924c9ff92a8780ce812511341182c6b509d45bc59f3f7b522e37225d24fc |
|
meshagent64-v2.exe |
Pre-configured Windows MeshCentral agent |
d83fdb9e53c5ff03c4cb0451ea1bebd79b53f29eadc1e2fa394c7af13a86ce2f |
|
meshagent32-azure-ops.exe |
Pre-configured Windows MeshCentral agent (32-bit) |
c7e9332731b06644fc73e0046a2a89eaa59b09f54250e9bd622467187351711f |
|
meshagent |
Unconfigured Linux MeshCentral agent |
68257a6f9ff196179ec03624e849927f26599eb180a7c82e14ef5bc4e93bc309 |
|
.bash_history |
Attacker command history |
2ab684d93c1553fad87041b4dea97188a97e78589deee2a7bacff905564f3a35 |
Unexpected .jsp files under <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/
Unauthorized files or directories under …/PSEMHUB.war/envmetadata/transactions/
Unexpected directories named logs, persistantstorage, or scratchpad under PSEMHUB paths
Recently created or modified .xml files under <docroot>/envmetadata/data/environment/ (potential XMLDecoder persistence)
Defacement and extortion marker file: README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT
HTTP POST requests to the following endpoints from external source IPs:
/PSEMHUB/hub
/PSIGW/HttpListeningConnector
Requests to /PSIGW/HttpListeningConnector containing loopback addresses (127.0.0.1, localhost, ::1) or internal IP ranges within request headers or parameters may indicate SSRF exploitation.
June 12, 2026: Initial publication.
Post Syndicated from jzb original https://lwn.net/Articles/1077718/
Hundreds of orphaned packages hosted by the Arch User Repository (AUR) have
been compromised by an attacker who has added a malicious npm
package (atomic-lockfile) that can exfiltrate sensitive
data. The project is currently working
on cleaning up the mess. There is a list of affected packages
and post (possibly NSFW domain) by
“sodiboo” with additional information. Arch Linux users (or users of
Arch-based distributions) that use AUR packages may wish to see if they
have installed any of the compromised updates.
Post Syndicated from jzb original https://lwn.net/Articles/1077703/
Security updates have been issued by AlmaLinux (.NET 10.0, .NET 8.0, .NET 9.0, bind, expat, httpd:2.4, kernel, kernel-rt, mod_http2, openssl, poppler, redis, redis:7, samba, and unbound), Debian (ironic, kernel-wedge, libinput, linux-base, and neutron), Fedora (kernel, openssl, vaultwarden, and vaultwarden-web), Mageia (erlang-hex_core, erlang-rebar3, gnupg2, and sqlite3), Red Hat (buildah, podman, and skopeo), SUSE (flannel, gdk-pixbuf-loader-libheif, gnutls, google-cloud-sap-agent, grafana, graphite2, hplip, libIex-3_4-33, libzypp, nginx, openssh, perl-DBI, perl-Git-Repository, perl-Protocol-HTTP2, python-Pygments, python-simpleeval, python311-Django4, rclone, roundcubemail, strongswan, tomcat10, tomcat11, unbound, and webkit2gtk3), and Ubuntu (apache2, dotnet8, dotnet9, dotnet10, gst-plugins-base1.0, ironic, linux-azure-5.15, linux-azure-fips, lwip, mistral, and ubuntu-kylin-software-center).
Post Syndicated from Dave Baxter original https://blog.cloudflare.com/scaling-security-scans/
Security Insights provides actionable security recommendations for every Cloudflare account. To find these insights, we perform regular scans for all accounts, zones, and DNS records, looking for potential security risks and misconfigurations.
However, two key issues emerged. First, our scans were too infrequent. Scans were only being performed every week or two, and therefore newly introduced security risks could remain undetected for up to two weeks. Second, automatic scanning was opt-in for many free plan accounts – meaning lots of accounts weren’t being scanned at all.
The risks of infrequent or nonexistent scans are rising: as automated attacks accelerate, the window for detecting security misconfigurations is shrinking. Making sure that we’re finding these issues for all of our customers is crucial to our aim of building a better Internet for everyone.
We calculated that to increase our scanning frequencies and enable automatic scanning for all accounts, we would need to increase our scanning throughput by around 10x on average – from 10 scans per second to 100 per second. But our system was already struggling with its load: millions of events were filling up our backlog waiting to be processed; our API was frequently timing out; our processes were crashing. We needed to fix our system, and we needed to make it scale.
This is the story of how we increased scanning throughput for Security Insights by more than 10x, enabled security insights for millions of customers, and doubled our scanning frequency for all customers. Read on to find out how we achieved these improvements.
At a high level, our automatic security scans are triggered by a scheduler. When an account or zone is due for a scan, the scheduler publishes a message (or messages) to Apache Kafka, an open-source distributed event streaming platform. These messages fan out to a number of checkers: specialized Go microservices that scan specific assets or configurations.
For every message, each checker sends its results (the security insights that it found) to our internal API, which then persists these in a Postgres database.
Apache Kafka is not strictly a queue: it is a partitioned event stream (though recently gained queue semantics). Within a partition, messages must be consumed and processed in order. This differs from typical queues where messages may be consumed in order but are processed out-of-order. As a result, we can only have one active consumer per partition within a consumer group.
This has two consequences for us:
Messages that are slow to process block the consumer from progressing to the next message
For each checker, we can only have as many consumers as there are partitions (each checker has its own consumer group)
We could have tried to scale by adding more partitions. However, this would have increased resource usage for the Kafka broker itself, which is shared by many other services. We reserved this as a last resort, aiming to improve our code and architecture first.
Although we can only consume messages in order, there is nothing stopping us from consuming multiple messages at once.
We changed our checkers to consume messages in batches, processing each message in a separate goroutine. The trade-offs are that we’d have more work to re-do if our process crashed midway through a batch, and our memory usage would be slightly increased. In our case, these were both acceptable.
Some messages processed by a few of our checkers take much longer to process than others. For example, one account/zone may have far more assets than another. In the worst case, these messages can take minutes or hours to process compared to the average case of seconds or milliseconds.
We opted for a very simple approach: splitting our consumer groups and checkers in two – the ‘slow lane’ and the ‘fast lane’. We could determine quickly whether a message would be slow or fast to process. If the ‘fast lane’ checker encounters a slow message, it skips it.
This solved the problem: slow messages had the dedicated resources and time to be processed with minimal delay, and fast messages were able to proceed at their regular fast pace.
Every insight we find gets written to our Postgres database. This is handled by a single API endpoint that our checkers invoke with a list of insights. The implementation looked like this:
for _, issue := range issues {
_, err = tx.Exec(ctx, `INSERT INTO table ... VALUES ($1, $2, ...) ON CONFLICT DO UPDATE ...`, ...)
if err != nil {
return err
}
}The astute reader will notice that for large sets of insights, this code makes a round trip to the database per insight. With a maximum observed size of 500,000, this was half a million round trips, queries, and transactions in a single API call.
We initially tried the gold standard for bulk inserts in Postgres: COPY into a temporary table. However, we found that this approach led to bloat in the Postgres system tables.
We settled on a hybrid approach:
Using UNNEST when the number of issues was below a threshold
Using COPY when the number of issues exceeded this threshold
This provided the best of both worlds: reasonably fast inserts for huge sets of insights (seconds), and even faster inserts (milliseconds) for small sets of insights.
We noticed several strange behaviours in our internal API as we tried to scale:
A large number of requests were triggering client-side timeouts
Many checkers were spending 20-90% of their processing time on a single API call
When triggering a large volume of scans, our throughput would start high and deteriorate
All of these problems had the same root cause: latency.
Our primary database is located in Portland, Oregon. Our API, however, was running active-active in both Portland and Amsterdam. Even at the speed of light, the round-trip latency between Portland and Amsterdam would be 50 milliseconds.
As a result of this latency, database queries from the Amsterdam API instance took much longer, holding connections from our client-side connection pool open. With the large volume of requests that we were making to the API, the connection pool was quickly becoming exhausted, leading to timeouts waiting for a free connection. Our average API call completed in 10 ms in Portland, but almost 3 seconds in Amsterdam!
But why the drop in message throughput? Each checker process gets assigned a set of partitions of the Kafka stream to consume. Our API is load-balanced. Since we hold the connection open throughout the life of the process, some processes had a connection to the Amsterdam API, and others had a connection to the Portland API. The partitions linked to Portland were processed quickly, but the ones consumed by the Amsterdam-bound processes were lagging behind:
Kafka lag (number of messages waiting to be processed within a single consumer group) by partition for one of our checkers. Note that we have 30 partitions in this case. Exactly 15 partitions can be seen lagging behind (the lines that reach or approach zero later than around 03/10 03:00). This is because the load balancer splits traffic evenly between our API endpoints.
This was a simple fix: we switched our API to active-passive, ensuring the active API followed our primary database. Our latency problems disappeared overnight.
We’d scaled Kafka. We’d optimised our database queries. We’d fixed our API. However, we still had a problem: we needed to be sure our scans would be roughly uniformly distributed in time. It wasn’t feasible to queue all of our scans at the same time, as our Kafka topic uses a time-based retention policy: the scans would pile up in Kafka, and eventually be deleted before they could be processed.
Our scheduler was not good at uniformly distributing our scans. The number of scans that would be triggered at a given time was spiky and unpredictable. At certain points throughout the week, hundreds of thousands of scans would be triggered within minutes of each other. What was going on?
The scheduler triggers scans on fixed recurring periods. In pseudocode, the scheduler looked like this:
Loop forever:
Find accounts where last_scheduled_at + scanning frequency <= now
For each account:
Trigger scan for account
Trigger scan for all zones in the account
Update last_scheduled_at = nowWe quickly noticed that last_scheduled_at was similar for a large number of accounts in our database, which was responsible for some of this unevenness.
However, even with perfectly even distribution, increasing our scanning frequency would have compounded this problem. For example, changing the scanning frequency from every 15 days to every seven days would mean 53% of accounts would suddenly be due for a scan.
There was a further problem with this logic. Some accounts have a very large number of zones. When these accounts were scheduled, there was a cascade of scans for all of their zones. This was saturating our Kafka partitions and leading to delays for scans of much smaller accounts.
To fix these problems, we made three key changes:
Schedule zones independently of accounts: each zone gets its own last_scheduled_at field.
Randomize the last_scheduled_at time for existing accounts and zones.
Introduce adaptive rate limiting for scan scheduling.
Scheduling zones independently was an obvious way to solve the problem of large accounts. Randomizing the last_scheduled_at time (and ensuring that no scans were delayed during this process) allowed us to fix the existing unevenness in our database.
Adaptive rate limiting is slightly more interesting. Rate limiting would allow us to solve the problem of a spike in scans when we change scanning frequencies. For example, if we wanted to increase our scanning frequency to every 7 days, and we had 50 million accounts, then a rate limit of ~83 scans/second would ensure that they were spread out evenly across 7 days.
But what if we added 10 million more accounts? Then, this rate limit would force us to take 8 days to scan all of these accounts. This is where the adaptive part comes in: the rate limit is asynchronously recalculated every half-hour based on the total number of accounts and zones we have, and our scanning frequencies. This ensures we continue scanning on time even if we onboard thousands or millions more accounts and zones.
func computeRate(free, pro, biz, ent int64) rate.Limit {
r := float64(free)/freeScanInterval.Seconds() +
float64(pro)/proScanInterval.Seconds() +
float64(biz)/bizScanInterval.Seconds() +
float64(ent)/entScanInterval.Seconds()
// Guard against zero counts. We always want to schedule at least one scan per second.
if r < 1 {
r = 1
}
// Increase rate limit beyond the 'perfect' value, to have a buffer in case of any downtime
// or spikes in load.
r *= rateLimitBufferFactor
return rate.Limit(r)
}
With these fixes, our 7-day moving average throughput per checker over time rose by more than 10x.
Before these improvements, we were executing around 10 scans per second. The gap between this and our target throughput of 100 scans per second seemed vast. We discussed throwing more resources at the problem, throwing more partitions at our Kafka topic – even throwing out our entire architecture.
But our fixes made all the difference. Today, Security Insights sustains over 120 scans per second during peak scheduling, exceeding our 10x improvement goal. Our internal API is no longer timing out, and our Kafka lag metrics look much healthier. These scalability improvements have allowed us to turn on automatic scanning for all free accounts and zones and increase the scanning frequency for all customers:
Free: every 7 days
Pro and Business: every 3 days
Enterprise: daily
The improved system stability has given us confidence to build new features that we were previously constrained from creating. We’ve added the ability to perform granular on-demand scans. You can now manually re-scan a Cloudflare account, zone, insight, or insight type.
Starting a granular on-demand scan from the Security Overview page in the Cloudflare dashboard
The lesson we learned is that it’s crucial to deeply understand the existing system before throwing anything away. By looking closely at our code, SQL queries, logs, and metrics (especially metrics!), we were able to increase our capacity without simply adding more pods or partitions. By questioning our assumptions, digging into weird-looking metrics, and refusing to take the easy shortcuts (such as increasing API client-side timeouts), we built a more stable and resilient system.
Throwing more resources at the problem might sometimes be the answer, but at Cloudflare, we believe in engineering our way out of problems.
Security Insights scans are enabled by default on all Cloudflare plans. Log in to the Cloudflare dashboard today to review and manage your security insights.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=uqIG1n7d0fY
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/bernie-sanders-ai-sovereign-wealth-fund-plan.html
Let no one accuse Bernie Sanders of ducking the big questions. Writing in the New York Times last week, the senator asked: “Will the future of humanity be determined by a handful of billionaires who have promoted and developed AI, with virtually no democratic input, who stand to become even richer and more powerful than they are today?”
We agree entirely that this is one of the most potent questions facing global democracy today. Our book, Rewiring Democracy, surveys the emerging uses for and impacts of AI in democracy around the world and reaches the same conclusion: that the most urgent risk posed by AI is the concentration of power, wealth and control among tech oligarchs.
And yet we reached a vastly different conclusion than Sanders on what to do about it.
The senator points to a once radical but increasingly popular solution: creating a US sovereign wealth fund by taking 50% stock in AI companies such as Anthropic, OpenAI and xAI. The argument in favor of this is twofold. One: it would establish democratic control over the AI companies, giving the government “the power, through its voting shares and an equal representation on each company’s board, to block decisions that hurt our citizens and to push for policies that help them”. Two: it would return a big chunk of the economic rewards of soaring AI valuations to the public, ensuring “trillions of dollars potentially generated by AI are used to improve the lives of all of us”.
We laud both these goals unreservedly.
We wholeheartedly agree that there must be public influence over the development and use of AI, just as we demand the government intervene to ensure that automakers, drugmakers, airlines and other industries balance profitability with public safety and the public interest. And we credit the senator with recognizing that there are more levers for the government to pull beyond the promulgation of regulation to achieve this.
And we also agree that the obscene, dangerous accumulation of wealth among AI companies needs to be disrupted. As OpenAI and Anthropic race to be minted as the world’s latest trillion-dollar AI companies, we should recognize that—whether or not it constitutes a bubble—these staggering market capitalizations represent a transfer of wealth. The flow of money goes from the smaller businesses and actual people using AI, and being subjected to it, to the owners of these tech companies.
That includes the world’s 86 AI billionaires “seeking to maximize their power and profit” aiming to decide the “fate of humanity behind closed doors in Silicon Valley”, as Sanders said.
And yet, while we do not outright oppose the taking of AI company stock, or of a US sovereign wealth fund, there are better ways to achieve Sanders’ stated goals.
Public ownership of these companies entangles corporate profit and valuation with the public interest. It would incentivize the government to clear regulations, permit the exploitation of workers and users, suppress competition, encourage AI adoption regardless of the responsibleness of the implementation or appropriateness of the use case, and otherwise act on behalf of corporate interests.
After all, if growing, say, Nvidia from its first $5tn in value to its next $5tn also represents a doubling in value of this segment of the sovereign wealth fund, then you can expect the fund managers to support chip sales, foreign and domestic, with the same zeal as the company’s private investors.
This is not an effective way to influence corporations to act in the public interest. In fact, it makes corporate influence on the government more likely.
We should be wary of this possibility because we’ve seen it before. Ownership of substantial stakes in oil companies by the Norwegian sovereign wealth fund, the world’s largest, does not seem to have steered those corporations to pro-environmental policies. Instead, the Norwegian government’s dependence on those companies has inhibited them from taking climate action. Here in the US, public employee pension funds merit the same criticism: the fiduciary duty to generate wealth overwhelms any intention to direct their corporate holdings in the public interest.
A better answer is to separate the two goals. The standard way to share private rewards with the broader society that made them possible is taxation. Senator Elizabeth Warren has proposed an excise tax on datacenters’ energy use. Others have proposed an AI token tax, which has much the same effect.
As to the goal of reshaping AI in the public interest, we have proposed an AI Public Option. The concept is for governments, be it federal or state, to establish publicly developed and operated AI models run by public institutions under democratic control. The idea is not to eliminate corporate AI or to seize it as a public asset, but rather for government to provide a competitive baseline that private AI offerings must meet or exceed to win business—just like the notion of a healthcare public option.
The Swiss have trailblazed this approach. Apertus is a large language model built by Swiss public servants, researchers at Swiss universities, using appropriately licensed training data and pre-existing Swiss public supercomputing infrastructure powered by renewable energy.
While Apertus doesn’t seriously compete with the latest OpenAI and Anthropic models on performance benchmarks, it blows them out of the water in transparency, sustainability and compliance with EU regulations including adherence to copyright. It’s a nascent project, but suggestive of how public institutions can apply competitive pressure for corporate actors to behave responsibly.
Don’t confuse public AI with “sovereign AI“, the notion that every country needs to invest in domestic AI infrastructure. Sovereign AI is often invoked as a marketing scheme for big tech companies looking to sell to governments; it demands public investment without guaranteeing public control.
Sanders is a bold and savvy political operator. So why is he pursuing the sovereign wealth fund strategy when he must be aware of these risks? It may be due to another argument he makes in his op-ed: that the Trump administration and the billionaire owners of AI are aligned to the idea.
It’s expedient to capitalize on rare moments of seeming alignment across diverse political factions, but it also behooves us to ask why the AI billionaires are open to this extraordinary intervention. The answer, of course, is that they believe that for every dollar ceded to government stock expropriation, they will get back more in favorable government policies to protect that newfound investment.
Energy taxation is a straightforward way to make AI companies pay for the social disruption of their technologies. Public AI represents a non-monetary mechanism for governments to shape the development of AI, complementary to direct regulation of private actors, one with a far greater chance of influencing corporate behavior towards the public interest. We urge Sanders and other political leaders to consider them.
This essay was written with Nathan E. Sanders, and originally appeared in The Guardian.
Post Syndicated from Емилия Милчева original https://www.toest.bg/mashallah-bulgari/
„Машаллах, българи!“, ще каже турският президент Реджеп Тайип Ердоган, който бил склонен на тактически отстъпки по споразумението с „Боташ“. И ще е прав, защото ще прибере стратегическата печалба благодарение на български политици.
За целта на официално посещение в България беше министърът на външните работи на Турция Хакан Фидан – един от най-близките хора на президента Ердоган. В продължение на 13 години Фидан оглавяваше турската разузнавателна служба (MİT), превръщайки я според анализатори „в своеобразно „острие“ на турската външна политика“ и изпълнявайки специални задачи, възлагани му лично от Ердоган.
Преди посещението той даде интервю пред кореспондентката на БТА в Турция Айше Сали, от което стана ясно, че Анкара ще използва неизгодното за България споразумение с „Боташ“ като разменна монета за свои геополитически цели. Срещу облекчаване на условията Анкара поставя на масата магистрали, гранични пунктове, енергийни връзки и една много по-голяма цел – да затвърди ролята си на незаменим посредник между Азия и Европа.
Мирослав Зафиров
Въпреки че България обича да се (само)нарича врата към Европа/Изтока (в зависимост от коя страна се отваря), Турция иска да държи ключовете. Географията е дала на България мястото. Политиката решава кой ще се възползва от него.
А всичко започва на 3 януари 2023 г., когато „разменната монета“ вече е факт.
В действителност – по-рано.
Буквално три седмици след като президентите на двете страни Румен Радев и Реджеп Тайип Ердоган договориха мащабно сътрудничество между нашите две държави, ние успяхме да превърнем тяхната инициатива в практическо решение, което дава възможност за взаимноизгодно развитие в сферата на енергетиката.
Росен Христов, министър на енергетиката в служебния кабинет на Гълъб Донев, понастоящем прясно назначен в Държавната консолидационна компания
Сключеното от един от служебните кабинети на президента Радев споразумение между турската държавна газова компания „Боташ“ и българската „Булгаргаз“ осигурява достъп на България до турските терминали за втечнен природен газ и до турската газопреносна мрежа. Независимо дали използва капацитета за пренос на до 1,5 млрд. куб.м газ годишно България е задължена да плаща на Турция по 537 000 евро (1,050 млн. лв.) на ден. Служебното правителство, което управляваше няколко месеца, сключи 13-годишния контракт (който не определя като договор, а като споразумение, защото иначе щеше да се изисква ратификация от парламента).
Газовото съглашение е критикувано заради високите фиксирани такси и след сключването му се правеха плахи опити за неговото предоговаряне. „Булгаргаз“ настоява за намаляване на количествата и срока на споразумението и за промени на тарифите. ГЕРБ, „Демократична България“, „Продължаваме промяната“ и олигархът Делян Пеевски нееднократно атакуваха президента Радев заради аферата „Боташ“. Временна парламентарна комисия проверяваше споразумението, а докладът и документацията бяха изпратени в прокуратурата.
Емилия Милчева
След изборната победа на „Прогресивна България“ и Румен Радев, осигурила му абсолютно управленско мнозинство, критиките заглъхнаха. Проблемът обаче не изчезна – превърна се в предмет на преговори и е използван като инструмент за натиск.
Аферата „Боташ“ вече е в нова опаковка – предмостие към по-здрава енергийна свързаност. След срещата си с първия турски дипломат премиерът Румен Радев публично не спомена споразумението, той говори за Турция като за „ключов партньор“ и постави фокус върху „енергийната и транспортна свързаност“ по време на разговорите. Външната министърка Велислава Петрова-Чамова, която също се срещна с Фидан, представи подобна версия:
По отношение на енергетиката, която остава ключова област, разгледахме доставките на природен газ, междусистемната свързаност и диверсификацията на енергийните ресурси.
Eдна протоколна снимка от срещата между двамата дипломати, на която Петрова е с открити рамо и коляно, предизвика язвителни коментари в социалните мрежи. България щяла да предоговаря „Боташ“ с голо рамо, шегуваха се потребители. По-късно снимката беше премахната от сайта на МВнР, но остана в публикациите на турското Външно министерство. Лошото е, че докато обществото се смееше на снимката, турската страна всъщност демонстрираше далеч по-сериозна преговорна стратегия от българската.
Нито Радев, нито Петрова-Чамова излязоха извън клишетата и общите фрази за конкретните искания на Анкара. Добре че го беше направил външният министър на Турция с интервюто си пред БТА дни преди гостуването си.
А след срещата във Външно Фидан даде да се разбере, че има правомощия от най-високо ниво да разреши проблема с „Боташ“.
От времето, когато господин Радев беше президент, следим отблизо тази тема. Проведохме няколко обсъждания и бяха дадени инструкции за разрешаването на този въпрос.
Турция обвързва своята готовност да обсъди промени по договора с „Боташ“ срещу пакет от проекти: увеличаване на газовия и електропреносния капацитет към Европа, магистрала „Черно море“, разширяване на ГКПП „Капитан Андреево“ и нови гранични пунктове. Всички те обслужват голямата турска амбиция да се утвърди като основен енергиен и транспортен коридор между Азия и Европа. Така че решението на проблема „Боташ“ за България, което е и добре изигран ход от Турция, всъщност представлява още повече предимства за югоизточната ни съседка.
Цената е България да подкрепи инфраструктурни проекти, които дават на Турция по-голям контрол върху потоците от стоки и енергия между Азия и Европа. Фидан говори не за предоговаряне на условията по „Боташ“, а за тяхното надграждане. Турция предлага всеобхватно енергийно споразумение, включващо увеличаване на капацитета за пренос на природен газ между двете страни. Казано по-просто, вместо разговорът да се води как България да плаща по-малко за достъпа до турската инфраструктура, Анкара го пренасочва към въпроса как през същата тази инфраструктура да преминават още по-големи количества газ към Европа.
Освен двустранно сътрудничество, договорът между „Боташ“ и „Булгаргаз“ включва инфраструктура, която ще допринесе и за енергийната сигурност на Европа.
Нашата цел е, подписвайки всеобхватно споразумение за сътрудничество в областта на енергетиката, което ще включва увеличаване на капацитета за пренос на природен газ между Турция и България, да развием още повече отношенията си.
Хакан Фидан
Разширяването на ГКПП „Капитан Андреево“ също не е случайно. Това е най-натовареният сухопътен граничен пункт между Турция и Европейския съюз и едно от най-важните трасета за товарния трафик между Азия и Европа. Всяко намаляване на задръстванията и увеличаване на пропускателната способност означава по-бързо и по-евтино придвижване на турски и азиатски стоки към европейските пазари. Същата логика стои и зад идеята за нови гранични пунктове.
Магистрала „Черно море“ далеч не е български инфраструктурен проект. За Турция тя е част от много по-голяма транспортна схема. В началото на годината стана известно, че турски строителни компании искат да изградят на концесия магистрала „Черно море“ от границата с Турция при Малко Търново чак до Дуранкулак при Румъния. Заедно с коридорите от Централна Азия, Кавказ и Ирак към турска територия това би улеснило движението на товари от Азия към европейските пазари. От турска страна дори предлагали към стоте километра магистрала и два скоростни пътя – от Малко Търново до Бургас и от Варна до Дуранкулак.
Защо „Черно море“ е толкова важна за Турция? Тя ще свърже Истанбул с Варна, Румъния, Молдова и Украйна. Така турските товари ще се придвижват много по-бързо до пристанищата в Констанца и Одеса. Турската страна обвързва изграждането ѝ с разширяването на ГКПП „Малко Търново – Дерекьой“.
Емилия Милчева
Общото между всички тези проекти е, че увеличават капацитета на коридора Турция–България–Европа. Затова Анкара ги поставя редом до въпроса за „Боташ“: като част от една по-голяма стратегия, а не като отделни инфраструктурни инициативи.
По време на срещата си с президентката Илияна Йотова Хакан Фидан е обсъдил железопътната инфраструктура и фериботна линия между Бургас и Истанбул. Според официалното съобщение двамата са отбелязали, че затрудненото движение през Ормузкия проток създава необходимост от алтернативни маршрути, което увеличава стратегическото значение на Югоизточна Европа.
Любопитна подробност от посещението на Хакан Фидан е, че освен с премиера, президентката и външната министърка, Хакан Фидан се срещна и с лидера на ДПС – олигарха и санкциониран по „Магнитски“ Делян Пеевски. Същият Пеевски, който определяше споразумението с „Боташ“ като един от примерите за лошо управление и настояваше за политическа отговорност за сключването на договорката.
Румен Радев също смяташе да разгражда олигархичен модел, чието назоваване му беше трудно, а след изборите на 19 април изобщо спря – и да назовава, и да говори за демонтаж на модела. Самият Пеевски и парламентарната му група се оказаха и поддръжници на инициативите на управляващото мнозинство.
Срещата на Хакан Фидан с Пеевски е съзнателен политически сигнал. Тя показва, че когато Турция обсъжда стратегически теми като енергетика и транспортни коридори, Анкара разговаря и с фигура, която има място в стратегическите отношения между България и Турция. Това е неудобен, но показателен знак как декларациите отстъпват пред политическата реалност.
Преди година и половина сделката с „Боташ“ беше представяна като едно от най-тежките наследства на служебната власт. Днес същото споразумение се използва като отправна точка за нов пакет от енергийни и инфраструктурни проекти между България и Турция.
Машаллах, българи…
Post Syndicated from Георги Тотев original https://www.toest.bg/ostrovut-na-prokudenite-travmi-ot-minaloto-izpluvat-po-bregovete-na-gyokcheada-purva-chast/
Небето е осеяно с цветове – десетки кайтсърф крила се носят над бурната вода, теглейки сърфистите мощно по вълните. На плажа туристи аплодират всеки зрелищен трик. Сред тях има семейства с деца, жени с хиджаб, но и в доста по-оскъдни бански костюми. Най-многобройни са заклетите кайтсърфисти, които подготвят екипировката си за следващото влизане във водата.
Изневиделица небето се разсича от изтребител – напомняне за турските военни бази навсякъде наоколо, които зорко охраняват входа на Дарданелите. В морето един от сърфистите се отличава със своята техника – буквално се изстрелва на десетки метри във въздуха, завърта се в сложна акробатична фигура и се връща отново сред вълните. От плажа отново се разнасят ръкопляскания.
Роден е в Кандахар и израства в сянката на продължителната международна военна интервенция в страната. Остава сирак още като дете. Отгледан е от чичо си, който не е имал постоянна работа. Махмуд работи от малък и помага за издръжката на домакинството. Учи вечер, а през деня продава каквото успее на улицата – флашки с пиратска музика, евтина козметика и дребни стоки, внесени от Китай. „Проблеми у дома и война по улиците“, обобщава детството си той.
Планът му бил прост: да спести пари, да завърши училище и някой ден да стигне до Европа – за предпочитане Германия. Бил убеден, че не е толкова трудно, колкото всички твърдят.
Човек трябва да има някаква причина да живее,
казва той.
Плажът е истински рай за кайтсърфистите – широк, пясъчен, див и с постоянен вятър. По брега са наредени десетки, ако не и стотици кемпери и каравани с регистрационни номера от различни държави в региона. Туризмът тук е сравнително ново явление. До началото на века Гьокчеада е затворена военна зона.
Днес островът, известен и като Имброс (гръцкото му име до 70-те години на миналия век), посреща около 13 000 туристи годишно. Повечето идват от континентална Турция, но има и от България, Румъния, Северна Македония и Полша.
Пътеводителят Rough Guide определя Гьокчеада като „блажено убежище от презастроеното Егейско крайбрежие на континентална Турция“. Според Lonely Planet островът е „скрито съкровище“, останало задълго в сянката на близкия полуостров Галиполи, но постепенно печелещо популярност като спокойно място за семейна почивка.
Още със слизането от ферибота усещаш острова с цялото си тяло – слънце, вятър и лек солен дъх от морето. Пейзажът е див и суров: маслинови горички, накъдето и да погледнеш, а по склоновете спокойно пасат кози. Лесно можеш да се изгубиш тук за няколко дни и да отнесеш спомена със себе си в снимките на телефона си. Но зад ваканционните кадри се крие друг Гьокчеада: за едни той е изгубен дом, за други – място на изгнание, а за трети – просто спирка по пътя.
—
Далеч от ветровитото крайбрежие, навътре в острова, въздухът е неподвижен, а времето сякаш тече по-бавно. Идиличният облик на мястото е отразен дори в името му – „гьокче“ на турски означава „небесен“, а „ада“ – „остров“. Сред маслиновите дървета край село Ширинкьой се намира фермата на Раиф и Кание Чалъшкан. Но двамата не са тук по собствено желание. Кание и Раиф са родом от българска Добруджа. Тя е израснала край Генерал Тошево, а той – в село близо до Крушари. Семействата им са част от турското малцинство в България. Младостта им преминава по времето на Тодор Живков – дългогодишния лидер на комунистическа България.
„Живеехме добре – спомня си Кание. – И до днес се радвам, че съм родена в България, че съм живяла там.“ Раиф е на същото мнение:
Бяхме като братя и сестри – турци и българи. Нямаше значение кой какъв е.
През 80-те години обаче турското малцинство се превръща в мишена на насилствена асимилационна кампания. В крайна сметка стотици хиляди души са принудени да напуснат родните си места в най-мащабното етническо прочистване в Европа по време на Студената война, отстъпващо по размер единствено на прогонването на немскоговорещото население от Централна и Източна Европа след края на Втората световна война.
„Никога не сме си представяли, че ще се озовем да живеем на остров – казва Раиф. – Това място така и не ни стана дом.“ Кание тихо го допълва:
Това не беше част от плана. Ако зависеше от мен, отдавна щях да съм си тръгнала оттук.
След падането на режима на Живков дискриминационните политики са отменени, но общественият разговор за този мрачен епизод от българската история дълго остава непълен и силно политизиран. Днес е по-видим – присъства, макар и бегло, в учебниците по история, изследва се от учени и често е посочван от защитниците на демокрацията като пример за престъпната същност на комунистическия режим.
Раиф и Кание © Георги Тотев
Към днешна дата отношенията между София и Анкара са може би най-добрите в съвременната история и изглеждат все по-малко склонни да се връщат към онези страници от миналото. Историята обаче продължава да живее – най-вече в спомените на хората, които са я преживели, запълвайки празнината между живота, който са били принудени да оставят зад гърба си, и онзи, който са се опитали да изградят.
—
Масите на уютно кафене са се разлели върху малкия павиран площад в края на улицата. Въздухът е изпълнен с шумни поздрави и клюки, разменяни на гръцки. Изглежда, че всички се познават. Виолета Патиниоти прибира лаптопа си след поредния работен ден за технологична компания в Атина, но далеч не бърза да си тръгва. По пътя към изхода спира на всяка крачка, заговорена от други посетители. Около нея избухва смях, ръце жестикулират оживено, а сбогуванията звучат така, сякаш могат да продължат безкрайно. На вратата се засича с Димитрис – собственика на заведението. Той е роден в Солун, но винаги е знаел, че островът е родното място на майка му. Преди десет години решава да се премести тук. „За да открия корените си – казва той. – И за да си изкарвам прехраната.“
Виолета също е тук сравнително отскоро. Родена е на остров Санторини. Учи археология във Великобритания. В Истанбул среща бъдещия си съпруг – турски художник по осветлението с кюрдски и арабски корени. Той работил по филм, сниман на острова, и двамата постепенно започнали да си представят Гьокчеада като място, където да отгледат двете си деца. Когато избухва пандемията от COVID-19, семейството взема окончателното решение да се премести тук, заменяйки шума на мегаполиса със спокойствието на островния живот. Допълнителен стимул е и решението на властите отново да разрешат отварянето на училища с преподаване на гръцки език.
Искахме децата ни да знаят и гръцки, и турски, да разбират и двете култури. Този остров е истинска мозайка от култури. За мен е рай. Но тук има и дълбоки рани, които все още не са зараснали и за които не е лесно да се говори,
казва Виолета. Кафенето е едно от най-новите популярни места за срещи на гръцката общност на острова, съсредоточена основно в град Гьокчеада и в селата Зейтинли, Тепекьой и Дерекьой. Според преброяване от 2023 г. общността се състои от около 700 души при общо население на острова от приблизително 11 300 жители. С други думи, за около един на всеки 20 жители на острова гръцкият е майчин език. По-голямата част от населението обаче е от турски произход и се е заселила тук едва през последните десетилетия, идвайки от различни части на континентална Турция.
Другото име на острова – Имброс, е свързано с древногръцката история. Споменава се в „Илиада“ на Омир като скалист остров над подводната пещера, където морският бог Посейдон държал конете си. Археологически находки показват, че островът е бил населен още през каменната епоха. През XV век Гьокчеада става част от Османската империя. Както и на други места в империята, православното християнско население запазва своите църкви и училища. В същото време обаче местните общности остават уязвими на политиките на принудителни преселвания, които периодично променят етническата карта на региона.
С разпадането на Османската империя в началото на XX век Гърция за кратко поема контрола над Имброс и съседния Тенедос – днешния Бозджаада. И двата егейски острова по това време имат преобладаващо гръцкоговорещо население. Съдбата им обаче е решена с Лозанския договор от 1923 г., който ги оставя в границите на новосъздадената Република Турция. Договорът урежда част от конфликтите, съпътствали разпадането на Османската империя, и предвижда задължителна размяна на население между Гърция и Турция – първата подобна мащабна операция, основана на религиозен признак. В резултат на това над един милион православни християни, говорещи гръцки език, са принудени да напуснат територията на Турция, а близо половин милион мюсюлмани, говорещи турски език, са изселени от континентална Гърция и гръцките острови.
Православното християнско население на Имброс и Тенедос – според различни оценки между 4000 и 9000 души – е изключено от размяната. Съгласно Лозанския договор Турция поема ангажимент да гарантира автономията и специалния статус на двете островни общности. Тези гаранции обаче остават само на хартия. Последвалите мерки карат много от гръцките жители на островите да се изселят в континентална Гърция. До края на 1923 г. Турция вече е установила пълен контрол над Имброс и Тенедос.
През останалата част от XX век гръцката общност на острова постепенно се стопява до едва няколкостотин души. Причината е поредица от политически мерки, насочени срещу нейния език, културна идентичност и имуществени права.
„Мнозина предпочитат да станат „бежанци“ в Гърция, вместо да останат чужденци, примирени със съдбата си на земята, на която са родени“, казва той.
През последните 20 години част от мерките са отменени, а някои от правата, отнети на гръцката общност през миналия век, са възстановени. Малък брой потомци на някогашните жители са се завърнали на острова, което поражда предпазлив оптимизъм за бъдещето на общността. Въпреки това темата продължава да бъде чувствителна в Турция. Според Юмит Есер, с изключение на ограничен кръг критично настроени към официалните наративи учени, „преобладаващата нагласа в турското общество дълго време е по-скоро безразличие или мълчание, отколкото открит разговор за тази част от миналото“.
Този материал е създаден в рамките на Програмата за журналистически постижения (Fellowship for Journalistic Excellence) с подкрепата на ERSTE Foundation и в сътрудничество с Balkan Investigative Reporting Network (BIRN).
Редактор на оригиналния текст: Нийл Арън
Превод: Георги Тотев
Post Syndicated from original https://www.toest.bg/biser-dyankov-iskame-s-vsyaka-igra-da-nauchavame-neshto-novo/
С игри като „Цар: Тежестта на короната“ (Tzar: The Burden of the Crown), „Да оцелееш на Марс“ (Surviving Mars), „Виктор Вран“ (Victor Vran), студио „Хемимонт Геймс“ (Haemimont Games) беше престижното лице на българските видеоигри. Какво наложи и какви ще са последствията от това, че станахте клон на „Парадокс“ (Paradox)?
Не сме клон. Ние си запазваме идентичността, вътрешната култура, нашия начин на работа, нашите ценности. Работим по нашия вид игри. Ако „Парадокс“ искаха просто да отворят „Парадокс София“, безкрайно по-лесно и по-евтино за тях щеше да бъде да си наемат офис и нови хора. За сделката, която сключихме – никога идеята не е била да станем техен клон. Нашата ценност за „Парадокс“ е, че сме тези, които сме. Например аз съм изпълнителен директор, но студиото се управлява и продължава да се управлява от Габриел Добрев, който е студио мениджър.
Ти си юрист по образование. Как се озова в сферата на видеоигрите?
Постъпих на работа в „Хемимонт Геймс“ през 2009 г. като дизайнер. Тогава работехме по последната от старите римски игри и по „Тропико 3“ (Tropico 3) – успешен проект, който много обичам. Знам, на пръв поглед звучи изненадващо. Спомням си момента, в който трябваше да говоря с родителите си как техните представи за мен няма да се случат, но всъщност далеч не съм единственият юрист, когото познавам и който се занимава с разработка на игри.
Но как все пак се случи при тебе?
Интересувах се от игри още през 90-те и попаднах в първите онлайн общности, които се сформираха тогава по интереси. Те бяха изключително малки. Имаше момент, в който се събра българският интернет – 200 души хлапета от всякакви градове. Студенти и гимназисти основно, в такава възраст бяхме. Така се запознах с много от хората – една част от тях правеха игри за удоволствие, а после започнаха да правят игри професионално. Аз така разбрах, че въобще има хора, които това правят. Години по-късно, през 2008-ма – „Юбисофт София“ (Ubisoft Sofia) съществуваше вече, „Блак Сий“ (Black Sea) съществуваше, – благодарение на такива приятелски контакти, отивайки за един концерт, имах шанса да си говоря дълго с Габи (Габриел Добрев – б.а.). И на следващата година започнах работа в „Хемимонт Геймс“ като дизайнер.
Тъй като ние издавахме игри с доста висока скорост, някак си естествено от един момент насетне започнах да се занимавам все повече с продуциране. Там имаше най-голям глад и най-голяма нужда. В една малка компания като нашата всеки носи по много шапки, изпълнява много роли. Никога не ни е пукало какви точно са титлите ни. Просто има работа за вършене. И аз прецених, че моят най-голям ефект върху целия екип и върху проектите, по които работим, е да се фокусирам върху продуцирането.
И така, това приключение продължава и до днес. Всеки един проект е самостоятелен и има своите собствени предизвикателства. Завършването на даден проект е някакво чудо. Каквато и игра да излезе, фактът, че от бял лист хартия се стига до нещо, което хората ще играят, е само по себе си невероятно преживяване. Един от огромните плюсове човек да работи в „Хемимонт Геймс“ е, че участва в този процес и може да го наблюдава отвътре. Докато много от колегите, които работят в другите фирми в София, знаят какви игри ще правят, още преди да постъпят на работа.
Тоест играта идва като задача, подготвена вече от други.
Да. „Юбисофт София“ правят игри на Ubisoft, „Криейтив асембли“ (Creative Assembly) правят „Тотална война“ (Total War)… Естествено, това е разумно и нормално от бизнес гледна точка. Но аз знам от кухнята, че няма проект, който да можеш да отделиш от неговата продуктова реалност. Идеята, че от едната страна има едни творци, които в балонче нещо си творят, а то после се сблъсква с хората с вратовръзки, никога не ми е звучала убедително. Смятам, че в това, което виждаме накрая като игра, е вплетена продуктовата реалност и тя не трябва да бъде изключвана.
Но от това, което казваш, виждам, че вие сте приятелски свързан екип, имате история, обща идентичност… Правилно ли съм разбрала, че има елемент, който ви прави различни от обичайните мегакомпании?
Абсолютно. И това, между другото, е както плюс, така и минус. Имаме страшно много история и сме запазили през годините сърцевината на екипа. Това означава, че имаме много ниско текучество. Това пък от своя страна означава две неща. Не сме толкова добри в интегрирането на нови хора в сравнение с една организация с по-добре установени процедури и корпоративни структури. Защото ние като групичка си знаем как правим нещата. Имаше много интересна ситуация, когато минахме от работа върху един проект към работа по няколко проекта. Тогава с изненада разбрахме, че дадени проблеми съществуват, но човекът, който винаги ги е решавал, сега работи по другия проект. И ти изведнъж трябва да се справяш с неща, за които никога не си мислил. Междувременно в другия проект е същото – има непознати за тях проблеми, а човекът, който досега ги е решавал, вече е на масата на съседната игра…
Кадри от „Виктор Вран“ (Victor Vran) и „Цар: Тежестта на короната“ (Tzar: The Burden of the Crown)
От многото игри, които сте правили, кои смяташ са най-представителни за вас като студио?
Какво точно наричаш представителни? Може да ги гледаш от различна гледна точка. „Цар“ е много известна в България; римските ни стратегии са много известни в Испания и до ден днешен…
Аз си спомням например, че „Да оцелееш на Марс“ излезе в някакъв звезден, или да го наречем марсиански момент…
О, това беше изумително! Да избереш каква точно игра да правиш е поразителен процес, защото той трябва да е съобразен с твоите силни и слаби страни като екип. Индитата (независимите екипи – б.а.) просто правят играта, която искат да направят: което е добро, то ще остане, всичко друго ще падне. Екипите с опит обаче трябва да са изключително внимателни, защото отговорността е друга и факторите са много. Сред факторите ние винаги сме включвали нашето разбиране накъде отива пазарът за видеоигри, какво правят другите студиа, какъв е, грубо казано, цайтгайстът. Нашите опити да сме в унисон с цайтгайста винаги са били не толкова успешни, с изключение на Марс, където – ама буквално – всичките планети се наредиха по един невероятен начин. Илън Мъск по това време популяризираше идеята за вертикално кацащи и излитащи ракети – очевидно това трябва да го има, за да е възможен двустранен транспорт. Ние първо си направихме визуално образите на нашите ракети, а Мъск няколко месеца преди излизането на играта пусна едни видеа, където ракетите бяха идентични. Не мога да ти кажа на колко интервюта са ме питали: „Ами вие сега защо изкопирахте ракетите на Мъск?“ Можеш да си играеш с тоя въпрос по много начини, например: „Ами Мъск всъщност вероятно е изкопирал нашите ракети.“ Истината е, че когато правиш нещо, което се опитваш да е ново, ти никога не си сам. Винаги има още хора, които са на границата на новото и мислят в сходна посока. И пътищата съвпадат, темите съвпадат.
Игрите, които ти изброи в началото – „Виктор Вран“, „Да оцелееш на Марс“, „Цар“, – са различни. И това е абсолютно съзнателно. Ние като екип експериментираме целенасочено в различни жанрове. Един от въпросите, който сме си поставяли, когато сме избирали каква игра да правим, е: „Добре, какво ново ще научим ние като екип?“ Сега правят „Тропико 7“. Сигурно ние, тъй като доста бързо издаваме игри, щяхме да сме, да не казвам голяма приказка, може би вече на „Тропико 9“. Нямаше проблем да правим „Тропико“ оттук до края на света. Не е нашето нещо това. Искаме да вървим в различни посоки, защото искаме с всяка игра да научаваме нещо ново, да подобряваме технологията си и да увеличаваме инструментариума си, така че следващата ни игра да е по-добра от предишната.
Кадри от „Да оцелееш на Марс“ (Surviving Mars)
Как според тебе ще се отрази изкуственият интелект на качествата на игрите, най-вече на естетическите им качества?
Има много нива на употреба на изкуствения интелект. Тук дори не говоря за директната му употреба за творчество. Говоря за употребата му на техническо ниво, която ще позволи много по-висока продуктивност. В момента се оптимизират системи и писане на код с изкуствен интелект. Това не е нещо, което играчът ще види, но ни спестява усилие, което да бъде насочено в посоки, които играчът ще може види. Във всички случаи неизбежно според мен ще се създава директно съдържание с изкуствен интелект. И вече ще видим доколко то може да се разпознава, да бъде отхвърляно или харесвано от играчите, дали няма да направи игрите твърде подобни… Във всеки случай, екипите, които не използват изкуствен интелект, просто ще станат неконкурентоспособни – освен ако не се случи някакво външно събитие. Примерно, изчислителната мощ, която е необходима, да стане толкова висока, че да направи непосилна масовата употреба на изкуствения интелект в създаването на видеоигри. Но това е някакъв външен фактор. Или да се стигне плато, където да спре бързият растеж на технологията. Това е друга хипотеза. Но пак си мисля, че няма връщане назад. Едно от следствията обаче може да бъде, че ще има много по-малко отворени позиции за хора без опит, така че след десет години да платим неприятна цена, когато сегашните опитни хора напуснат и няма достатъчно опитни хора, които да ги заместят.
От друга страна, някои твърдят, че може да стигнем до ситуация, в която няма да има масови игри, а изкуственият интелект ще направи за всеки перфектната игра. Всеки ще играе собствената си индивидуална версия и разговорът по-трудно ще се води, защото аз няма да съм играл твоята игра.
Преди да е дошъл този момент, в който силно се съмнявам, да сменим темата. Какви компромиси в правенето на игри би искал да не ти се налага да правиш?
От гледна точка на процеса отвътре абсолютно всяка игра е компромис. Тя е недовършена и може да бъде по-добра. Няма завършена игра, има само изоставена игра.
Тя по презумпция завършва в действието на играча, така че е структурно и онтологически незавършена.
Окей, добре, съгласен съм, аз може би прекалено силно мисля от продуктова гледна точка. Има игри, които придобиват пълната си форма или потенциалът им става ясен в края на процеса на разработка. Едва в края разбираш каква игра е трябвало да направиш от самото начало, но процесът на разработка вече свършва и в останалите два месеца няма как да поправиш стореното. Евристичният процес е понякога много бавен, той не се подчинява на срокове. Да речем обаче, че имаш това време. Тук възниква друга опасност. Когато правиш една игра много дълго, ти се отдалечаваш от контекста, в който е била замислена. Затова си мисля, че нашият подход в „Хемимонт Геймс“ е много правилен. Ние никога не сме си поставяли за цел да направим най-добрата игра, на която сме способни. Винаги сме си поставяли за цел да направим по-добра игра от последната. Важното е да пренесем наученото към следващия цикъл. Между другото, това е една от причините, които правят „Парадокс“ толкова добър партньор за нас.
С оглед на всичко това как преценяваш шансовете българско студио да създаде международно признат шедьовър?
Леле! Тук, първо, не е много ясно какво е българско студио. „Хемимонт Геймс“ беше българско студио, няма спор. А сега, като е 100% собственост на „Парадокс“, продължава ли да е българско студио, при положение че креативният контрол си е наш? Creative Assembly българско студио ли е? Ubisoft Sofia българско студио ли е? При това ние сме много щастливи да имаме колеги, които не са българи. Етикетът „българско“ изобщо е под въпрос. Ама това е само началото. А какво означава „шедьовър“ и какво означава „международно признат“, също тотално не ми е ясно. Значи, нашите игри имат нещо, което на английски би звучало като cult following (последователи на култ – б.а.), „Да оцелееш на Марс“ е продала милиони копия, както и „Тропико“-тата. Ти по дефиниция продаваш в целия свят, тоест те са международно признати по дефиниция. А сега какво е шедьовър, от какво се определя? От продадени бройки или от това, че много ни е харесало на нас? Наградите ли имат значение? Тъй като съм наблюдавал отвътре как се правят игри, за да спечелят награди… Една игра може да е много наградена, обаче ако не е намерила своята аудитория, какво означава това? Така че целият този въпрос ми се струва в едни рамки, които при по-внимателен поглед не издържат.
Има обаче конкретни примери, с които мога да илюстрирам този въпрос – „Вещерът“ като полска игра, „Светлосянка“ като френска…
„Вещерът“ не е създаден във вакуум, а по успешна литературна поредица. В този ред имам какво да разкажа от опита ни с работа с писатели. Неведнъж сме се опитвали да работим с писатели. За да се получи, трябват ни образовани хора, но без гордостта, защото медията е друга и винаги се стига до сблъсък между дизайна на играта, която ние правим, и човека, който смята, че играта трябва да бъде точно такава, каквато той е решил. А това не е възможно. Играта не отговаря на индивидуалната фикция, защото са включени много хора, има много фактори. Самата работа в екип е винаги предизвикателство. Така че крайният резултат винаги в някаква степен е отвъд контрола на всички участници.
Кадри от „Шайка наемници 3“ (Jagged Alliance 3) и „Крушение: Извънземна зора“ (Stranded Alien Dawn)
За да се върна към въпроса за изкуствения интелект, виждам две възможни развития. Все повече студиа ще правят все по-еднакви игри. От друга страна, тъй като технически правенето им ще става все по-лесно, според мен ветрилото ще се разтваря и ще има все по-интересни и по-разнообразни игри. И това само по себе си крие потенциала на едно интересно и обещаващо бъдеще.
Да завършим с тази оптимистична прогноза. Благодаря ти от името на Игромислещия екип.
—
В рубриката „Игромислие“ публикуваме разговори, в които се срещат, съпоставят и противопоставят различни гледни точки към многоизмерния, многожанров феномен на видеоигрите – не толкова като електронен спорт, колкото като нов синтез на изкуствата и като ново поле на общуване и социалност.
Post Syndicated from Explosm.net original https://explosm.net/comics/pill-bugs
New Cyanide and Happiness Comic
Post Syndicated from xkcd.com original https://xkcd.com/3258/
