Post Syndicated from Patrick Kennedy original https://www.servethehome.com/broadcom-3-5d-xdsip-with-face-to-face-3-5d-for-2026-xpus-and-beyond/
Broadcom 3.5D XDSiP with Face-to-Face 3.5D packaging already has a number of design wins for big custom 2026 XPUs
The post Broadcom 3.5D XDSiP with Face-To-Face 3.5D For 2026 XPUs and Beyond appeared first on ServeTheHome.
Post Syndicated from jzb original https://lwn.net/Articles/1000927/
System76 has announced the
fourth alpha release of its Rust-based COSMIC desktop. New features
in this version include the ability to set default applications,
region and language settings, a new Accessibility applet, as well as
support for
variable refresh rate (VRR) in the cosmic-comp compositor and the
display settings tool. See the blog post for a full list of fixes and
performance improvements. LWN covered the first alpha
release in August.
Post Syndicated from jzb original https://lwn.net/Articles/1000485/
It has long been said that naming things
is one of the hard things to do in computer science. That may be
so, but it pales in comparison to the challenge of handling
usernames properly in applications. This is especially true when multiple
applications are involved, and they are all supposed to agree on what
characters are, and are not, allowed. The Debian project is facing
that problem right now, as two user-creation utilities disagreed about
which names are allowable. A plan is in place to sort this out
before the release of Debian 13 (“trixie”) sometime next year.
Post Syndicated from Talks at Google original https://www.youtube.com/watch?v=H8eBCOWQoio
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=BZgtoFaCbj0
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=1Zu3J7sBx-g
Post Syndicated from corbet original https://lwn.net/Articles/1000880/
Mozilla would
appear to have concluded that the solution to its problems is an
extensive rebranding effort:
We teamed up with global branding powerhouse Jones Knowles Ritchie
(JKR) to revamp our brand and revitalize our intentions across our
entire ecosystem. At the heart of this transformation is making
sure people know Mozilla for its broader impact, as well as
Firefox. Our new brand strategy and expression embody our role as a
leader in digital rights and innovation, putting people over
profits through privacy-preserving products, open-source developer
tools, and community-building efforts.
Post Syndicated from Rachel Arthur original https://www.raspberrypi.org/blog/addressing-the-digital-skills-gap/
The digital skills gap is one of the biggest challenges for today’s workforce. It’s a growing concern for educators, employers, and anyone passionate about helping young people succeed.
Digital literacy is essential in today’s world, whether or not you’re aiming for a tech career — yet too many young people are entering adulthood without the skills to navigate it confidently and recent research shows that many young people finish school without formal digital qualifications.
Whilst this challenge is a global one, we’re exploring solutions in England where computing has been part of the national curriculum for a decade and the option of studying for a qualification (GCSE) in computer science is available to many 14-year-olds.
The SCARI report shows that GCSE computer science isn’t available in every school in England, and even where it is available, only a fraction of students opt to study it. Where GCSE computer science is offered, the focus is not on broader digital skills, but more on programming and theoretical knowledge which, while important, doesn’t support young people with the knowledge they need to succeed in the modern workplace.
At the Raspberry Pi Foundation, we’re working with the Greater Manchester Combined Authority to tackle this challenge head-on. Together, as part of their Manchester Baccalaureate initiative, we’re developing a self-paced course and certification to tackle the digital skills gap directly.
The Raspberry Pi Foundation Certificate in Applied Computing is designed to be accessed by any pupil, anywhere. It includes a series of flexible modules that students can work through at their own pace. Targeted at young people ages 14 and up, the certificate covers three stages:
We recently visited Oasis Academy Media City to hold a workshop on digital skills and get input on the certificate. We welcomed educators and industry experts to share their insights, and their feedback has been invaluable.
Teachers pointed out a common challenge: while they see the importance of digital skills, they often lack the time and resources to add new material to an already packed curriculum. By offering the certification as bite-sized modules that focus on specific skills, it makes it easier to slot the content into the timetable, and helps students with limited access to school (due to illness, for example) engage with the course.
Educators were particularly excited about the opportunity for students to specialise in areas tied to in-demand roles that are currently being recruited for and our goal is to make the qualification engaging and relevant, helping students see how their learning applies in the real world.
We’re thrilled to share that, in November, we’ll be piloting this qualification in schools throughout Manchester. We’ll gather invaluable feedback from young people as they embark on this learning experience, which will help us refine the course.
Our full qualification will launch in 2025, and we can’t wait to help students approach their futures with curiosity and confidence.
The post Addressing the digital skills gap appeared first on Raspberry Pi Foundation.
Post Syndicated from jake original https://lwn.net/Articles/1000871/
Greg Kroah-Hartman has released the 6.12.2, 6.11.11, and 4.19.325 stable kernels. Note that both
6.11.11 and 4.19.325 are the last kernels in those series, “please move
“. In the 4.19.325 release notice, he has
off to a newer kernel version
a rather longer-than-usual message, including:
As a “fun” proof that this one is finished (and that any company saying
they care about it really should have their statements validated with
facts), I looked at the “unfixed” CVEs from this kernel release.
Currently it is a list 983 CVEs long, too long to list here.You can verify it yourself by cloning the vulns.git repo at
git.kernel.org and running:./scripts/strak v4.19.325Note, this does NOT count the hardware CVEs which kernel.org does not
track, and many are sill unfixed in this kernel branch.
Post Syndicated from jake original https://lwn.net/Articles/1000870/
Security updates have been issued by Fedora (thunderbird, tuned, and webkitgtk), Mageia (python-aiohttp and qemu), Oracle (container-tools:ol8, firefox, java-1.8.0-openjdk, java-11-openjdk, kernel, kernel:4.18.0, krb5, pam, postgresql:16, python-tornado, python3:3.6.8, thunderbird, tigervnc, tuned, and webkit2gtk3), Red Hat (bzip2, postgresql, postgresql:13, postgresql:15, postgresql:16, python-tornado, and ruby:3.1), Slackware (python3), SUSE (postgresql, postgresql16, postgresql17, postgresql13, postgresql14, postgresql15, python-python-multipart, and python3), and Ubuntu (python-django and recutils).
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=8Z1W-9rr4Xk
Post Syndicated from original https://www.toest.bg/za-borbata-na-naukata-s-hiv/
Човешкият имунодефицитен вирус (ХИВ), който причинява синдрома на придобитата имунна недостатъчност (СПИН), е открит през 1984 г. Около 40 млн. души живеят с ХИВ към 2023 г., а над 40 млн. са починали от СПИН от началото на епидемията. ХИВ инфекцията може да увеличи риска от развитие на рак, сърдечносъдови и костни заболявания и др. Откакто е установен първият случай на болестта, не спират да се търсят подходи за прекратяване на разпространението на вируса и за иновативни терапии, както и да се правят опити за разработване на ваксини.
През 1981 г. в Центъра за контрол и превенция на заболяванията (Centre of Disease Control – CDC) в Атланта, Джорджия, специалистката по разработка на лекарства Санди Форд оставя бележка на ментора си за забелязани пет случая на пневмония с необичайно протичане, като предполагаем причинител са микроскопични гъби, подобни на дрожди. Такива микроорганизми до онзи момент са били наблюдавани само при имуносупресирани пациенти. По това време дерматолози в САЩ отчитат увеличение на пациентите с агресивния и рядко срещан вид рак на кожата – сарком на Капоши. Общото между пациентите отново е, че имунната им система е силно потисната.
Случаите стават стотици и започват да се откриват и в Европа, Южна Америка и Австралия. Най-често засегнати са хомосексуални мъже, хора, които употребяват наркотици, работници в секс индустрията (и техните партньори), както и пациенти с хемофилия. Открити са и други симптоми на заболяването освен пневмонията и саркома на Капоши, включващи гърчове, остра загуба на телесно тегло, висока температура и развитие на други видове рак. През следващата година CDC използва термина синдром на придобитата имунна недостатъчност (СПИН) и изказва предположението, че причинителят най-вероятно е все още неидентифициран инфекциозен агент.
През 1983 г. е изолиран вирус от лимфните съдове на пациенти със симптоми на СПИН. Той е класиран в семейството на ретровирусите. В този период учените откриват и начин как да размножат вируса в лабораторни условия, което служи и за разработването на патентован кръвен тест за наличие на ХИВ, който се използва и до днес. През 2008 г. Нобелова награда за медицина получават френските вирусолози Франсоаз Баре-Синуси и Люк Монтание за откриването на ХИВ.
С откриването на ХИВ вируса се появяват и много въпроси, чакащи своя отговор. Какъв е произходът на този вирус? Защо причинява толкова разнообразни симптоми? Защо в немалка част от случаите симптомите се развиват много късно (месеци или години) след инфекция с вируса?
Съществуват два ХИВ вируса: ХИВ-1 и по-рядко срещаният ХИВ-2. Те произхождат от сходни ретровируси, които се срещат при примати в Африка. Хората са се заразили с тях от приматите (зооноза), най-вероятно чрез консумацията на заразено месо.
ХИВ вирусът е изграден от белтъчна обвивка, а в сърцевината му се крие нуклеиновата киселина РНК. Всъщност ХИВ вирусът прилича по структура на SARS-CoV2 – вируса, който предизвиква COVID-19. Въпреки че и двата са РНК вируси, жизненият им цикъл в заразената клетка е напълно различен.
ХИВ вирусът се предава чрез телесни течности – основно чрез кръвен контакт, чрез сексуален контакт без предпазни мерки или от бременна жена на плода. Вирусът се прикрепва към определен вид клетки на имунната система – CD4 Т-клетки. Те са задължителна и основна част от правилното функциониране на имунната система. Ролята им е да дават инструкции на другите клетки на имунната система, които получават сигнал и атакуват нахлуващите патогени и увредени клетки.
При закачането на ХИВ вируса за помощните Т- клетки той вкарва своите РНК и ензими в клетката. Най-важният ензим от жизнения цикъл на ХИВ е т.нар. обратна транскриптаза. Този ензим има уникалната възможност да произвежда ДНК от РНК (по правилата на централната догма ДНК се превръща в РНК, но не и обратното). Понякога вирусната ДНК остава скрита и не работи дълго време, което дава възможност на вируса да се запази дори и ако множество клетки на гостоприемника умрат.
В заразената Т-клетка вирусната ДНК се вгражда в ДНК на клетката. Това е и причината ХИВ-позитивните да остават завинаги такива, тъй като няма ефективен механизъм, чрез който да се унищожи напълно скритият внедрен в генома вирус.
Инжектираните РНК и ензими в помощните Т- клетки служат и за производството на нови вируси, които излизат от клетката и заразяват други клетки. Друго предимство на вируса е огромният брой грешки, които се допускат от ензими при превръщането на РНК в ДНК. Незасегнатите помощни Т-клетки получават сигнали, че заразената клетка е „развалена“, и когато се притекат на помощ, падат в същия капан. По този начин тялото унищожава множество помощни Т- клетки, което нарушава цялата имунна система и се стига до имунна недостатъчност. Ето защо пациентите са в пъти по-податливи на инфекции и рак, както и на резистентност към дадено лечение.
От началото на епидемията от ХИВ се правят опити за разработване на антиретровирусни лекарства. През 2016 г. са създадени над 40 медикамента, които в различни комбинации държат инфекцията под контрол. До 2021 г. Американската агенция по лекарства и храни е одобрила над 220 антиретровирусни медикамента за лечение на СПИН.
От края на 90-те години заболеваемостта и смъртността в резултат на заразяване с ХИВ вирус намаляват значително с помощта на антиретровирусната терапия (АРТ). Освен това АРТ удължава продължителността на живота на пациентите. Разработените терапии атакуват различни ензими, които са задължителна част от жизнения цикъл на ХИВ вируса, и успешно държат вирусния товар в ниски граници, тоест не позволяват на вируса да се размножава и да инфектира здрави помощни Т- клетки). През последните няколко години усилията са насочени към разработването на антитела, които да се използват като ваксина, но това е доста трудоемка задача предвид факта, че ХИВ вирусът мутира прекалено често.
За да инфектира една помощна Т-клетка, ХИВ вирусът се закачва за два рецептора едновременно – CD4 и CCR5. Някои хора носят мутация в гена, който кодира CCR5 рецептора. Мутиралата версия на рецептора води до невъзможност за експресиране на рецептора на повърхността на клетката – CCR5 при тези хора липсва. Голяма част от хората, носители на мутацията, са с европейски произход. Носителите на мутация и в двете копия на гена са напълно защитени от инфекция от ХИВ, а носителите само на едно копие развиват заболяването по-бавно. Това откритие насочва учените към мисълта за генни терапии на базата на CCR5 рецептора.
През 2007 г. е извършена първата трансплантация на стволови клетки на ХИВ-позитивен пациент от донор с мутация в CCR5 рецептора. Пациентът прекъсва АРТ след успешната трансплантация, а ХИВ инфекцията изчезва напълно. Към днешна дата излекуваните от ХИВ чрез трансплантация на стволови клетки са седем, но тази манипулация крие сериозни рискове, например реакция на присадката срещу гостоприемника. Тоест имплантираните от донора клетки разпознават като чуждо тялото на реципиента, което води до възпаление в различни органи и е животозастрашаващо. По тази причина засега трансплантацията не може да стане широко приложима практика.
През 2018 г. китайският генетик Хъ Дзиенкуей използва CRISPR-Cas технологията, за да модифицира два човешки ембриона. Раждат се две близначки, носителки на мутацията в гена, произвеждащ CCR5 рецептора. Ученият е осъден от китайската държава за своя експеримент поради упражняването на незаконни медицински практики. Твърди се, че Хъ е фалшифицирал документи от етичната комисия – практически сам е написал, че комисията одобрява и дава право да извърши тази манипулация. След това е излъгал лекарите, които, бивайки подведени, са имплантирали генномодофицираните ембриони в две пациентки при инвитро процедура. Едната от тях е родила близначките, а при другата процедурата е била неуспешна.
Обръщаме внимание на този експеримент, защото въпреки неетичния аспект случаят неоспоримо доказва, че напредъкът в генетичните техники открива възможности за нови подходи за превенция и лечение.
Въпреки значителния прогрес в медицината през последните четири десетилетия, СПИН все още отнема живота на много хора по целия свят. Разработването на нови терапии за ХИВ инфекцията и кандидат-ваксините за превенция са надеждата за спирането на ХИВ/СПИН епидемията в глобален мащаб.
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=hmCco2Fet1s
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=3ud24B88sKU
Post Syndicated from corbet original https://lwn.net/Articles/998950/
The LWN.net Weekly Edition for December 5, 2024 is available.
Post Syndicated from Explosm.net original https://explosm.net/comics/invitation
New Cyanide and Happiness Comic
Post Syndicated from Grab Tech original https://engineering.grab.com/seamless-migration
At Grab, we continuously enhance our systems to improve scalability, reliability and cost-efficiency. Recently, we undertook a project to split the read and write functionalities of one of our backend services into separate services. This was motivated by the need to independently scale these operations based on their distinct scalability requirements.
In this post, we will dive deep into how we migrated the stream processing (write) functionality to a new service with zero data loss and duplication. This was accomplished while handling a high volume of real-time traffic averaging 20,000 reads per second from 16 source Kafka streams writing to other output streams and several DynamoDB tables.
Migrating the stream processing to the new service while ensuring zero data loss and duplication posed some interesting challenges, especially given the high volume of real-time data. We needed a strategy that would enable us to:
We considered various options for the switchover such as using feature flags via our unified config management and experimental rollout platform. However, these approaches had some limitations:
Ultimately, we decided on a custom time-based switchover logic implemented in shared code between the two services leveraging our monorepo structure. In the following sections, we will walk you through the steps we took to achieve this seamless migration.
First, since both the existing and new services reside in our monorepo, we moved the stream processing code from the existing service to a shared /commons directory. This allowed both the old and new services to import and use the same code. We added logic in this commons package to selectively turn stream processing on or off based on the service processing them.
Next, we created temporary “sink” resources such as streams and DynamoDB tables for the new service to write the processed data. This allowed us to monitor and validate the new service’s behavior in production without impacting the main resources.
In the shared /commons code, we added a map[string]time.Time to schedule the switchover for each stream.
map[string]time.Time{
"streamA": time.Date(2024, 2, 28, 12, 0, 0, 0, time.UTC),
"streamB": time.Date(2024, 3, 10, 12, 0, 0, 0, time.UTC),
// ...
}
When a stream is added to this map, it means it is scheduled for switchover at the specified time. This logic is shared between both services, so the switchover happens simultaneously. The new service starts writing to the main resources while the old service stops, with no overlap or gap.
To perform the switchover, we:
The old service continued consuming the streams for a short monitoring period post-switchover, but without writing anywhere, ensuring no loss or duplication at the output sink resources. Then, the stream consumption was removed from the old service altogether, completing the entire migration process.
Using this time-based approach, we were able to seamlessly migrate the high-volume stream processing to the new service with:
The whole migration, including the gradual stream-by-stream switchover, was completed in about three weeks.
One learning was that such custom time-based logic, while effective for our use case, has limitations. If a rollback was needed for any of the two services for some unexpected reasons, some data inconsistency would be unavoidable. Generally, such time-based logic should be used with caution as it can lead to unexpected scenarios if the systems fall out of sync. We went ahead with this approach as it was a temporary measure and we had thoroughly tested it before carrying out the switchover.
Grab is the leading superapp platform in Southeast Asia, providing everyday services that matter to consumers. More than just a ride-hailing and food delivery app, Grab offers a wide range of on-demand services in the region, including mobility, food, package and grocery delivery services, mobile payments, and financial services across 700 cities in eight countries.
Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!
Post Syndicated from Let's Encrypt original https://letsencrypt.org/2024/12/05/ending-ocsp.html
Earlier this year we announced our intent to provide certificate revocation information exclusively via Certificate Revocation Lists (CRLs), ending support for providing certificate revocation information via the Online Certificate Status Protocol (OCSP). Today we are providing a timeline for ending OCSP services:
Additionally, a very small percentage of our subscribers request certificates with the OCSP Must Staple Extension. If you have manually configured your ACME client to request that extension, action is required before May 7. See “Must Staple” below for details.
OCSP and CRLs are both mechanisms by which CAs can communicate certificate revocation information, but CRLs have significant advantages over OCSP. Let’s Encrypt has been providing an OCSP responder since our launch nearly ten years ago. We added support for CRLs in 2022.
Websites and people who visit them will not be affected by this change, but some non-browser software might be.
We plan to end support for OCSP primarily because it represents a considerable risk to privacy on the Internet. When someone visits a website using a browser or other software that checks for certificate revocation via OCSP, the Certificate Authority (CA) operating the OCSP responder immediately becomes aware of which website is being visited from that visitor’s particular IP address. Even when a CA intentionally does not retain this information, as is the case with Let’s Encrypt, CAs could be legally compelled to collect it. CRLs do not have this issue.
We are also taking this step because keeping our CA infrastructure as simple as possible is critical for the continuity of compliance, reliability, and efficiency at Let’s Encrypt. For every year that we have existed, operating OCSP services has taken up considerable resources that can soon be better spent on other aspects of our operations. Now that we support CRLs, our OCSP service has become unnecessary.
We recommend that anyone relying on OCSP services today start the process of ending that reliance as soon as possible. If you use Let’s Encrypt certificates to secure non-browser communications such as a VPN, you should ensure that your software operates correctly if certificates contain no OCSP URL.
Because of the privacy issues with OCSP, browsers and servers implement a feature called “OCSP Stapling”, where the web server sends a copy of the appropriate OCSP response during the TLS handshake, and the browser skips making a request to the CA, thus better preserving privacy.
In addition to OCSP Stapling (a TLS feature negotiated at handshake time), there’s an extension that can be added to certificates at issuance time, colloquially called “OCSP Must Staple.” This tells browsers that, if they see that extension in a certificate, they should never contact the CA about it and should instead expect to see a stapled copy in the handshake. Failing that, browsers should refuse to connect. This was designed to solve some security problems with revocation.
Let’s Encrypt has supported OCSP Must Staple for a long time, because of the potential to improve both privacy and security. However, Must Staple has failed to get wide browser support after many years. And popular web servers still implement OCSP Stapling in ways that create serious risks of downtime.
As part of removing OCSP, we’ll also be removing support for OCSP Must Staple. CRLs have wide browser support and can provide privacy benefits to all sites, without requiring special web server configuration. Thanks to all our subscribers who have helped with the OCSP Must Staple experiment.
If you are not certain whether you are using OCSP Must Staple, you can check this list of hostnames and certificate serials (11.1 MB, .zip).
As of January 30, 2025, issuance requests that include the OCSP Must Staple extension will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension.
As of May 7, all issuance requests that include the OCSP Must Staple extension will fail, including renewals. Please change your ACME client configuration to not request the extension.
Post Syndicated from Let's Encrypt original https://letsencrypt.org/2024/12/05/ending-ocsp/
Earlier this year we announced our intent to provide certificate revocation information exclusively via Certificate Revocation Lists (CRLs), ending support for providing certificate revocation information via the Online Certificate Status Protocol (OCSP). Today we are providing a timeline for ending OCSP services:
Additionally, a very small percentage of our subscribers request certificates with the OCSP Must Staple Extension. If you have manually configured your ACME client to request that extension, action is required before May 7. See “Must Staple” below for details.
OCSP and CRLs are both mechanisms by which CAs can communicate certificate revocation information, but CRLs have significant advantages over OCSP. Let’s Encrypt has been providing an OCSP responder since our launch nearly ten years ago. We added support for CRLs in 2022.
Websites and people who visit them will not be affected by this change, but some non-browser software might be.
We plan to end support for OCSP primarily because it represents a considerable risk to privacy on the Internet. When someone visits a website using a browser or other software that checks for certificate revocation via OCSP, the Certificate Authority (CA) operating the OCSP responder immediately becomes aware of which website is being visited from that visitor’s particular IP address. Even when a CA intentionally does not retain this information, as is the case with Let’s Encrypt, CAs could be legally compelled to collect it. CRLs do not have this issue.
We are also taking this step because keeping our CA infrastructure as simple as possible is critical for the continuity of compliance, reliability, and efficiency at Let’s Encrypt. For every year that we have existed, operating OCSP services has taken up considerable resources that can soon be better spent on other aspects of our operations. Now that we support CRLs, our OCSP service has become unnecessary.
We recommend that anyone relying on OCSP services today start the process of ending that reliance as soon as possible. If you use Let’s Encrypt certificates to secure non-browser communications such as a VPN, you should ensure that your software operates correctly if certificates contain no OCSP URL.
Because of the privacy issues with OCSP, browsers and servers implement a feature called “OCSP Stapling”, where the web server sends a copy of the appropriate OCSP response during the TLS handshake, and the browser skips making a request to the CA, thus better preserving privacy.
In addition to OCSP Stapling (a TLS feature negotiated at handshake time), there’s an extension that can be added to certificates at issuance time, colloquially called “OCSP Must Staple.” This tells browsers that, if they see that extension in a certificate, they should never contact the CA about it and should instead expect to see a stapled copy in the handshake. Failing that, browsers should refuse to connect. This was designed to solve some security problems with revocation.
Let’s Encrypt has supported OCSP Must Staple for a long time, because of the potential to improve both privacy and security. However, Must Staple has failed to get wide browser support after many years. And popular web servers still implement OCSP Stapling in ways that create serious risks of downtime.
As part of removing OCSP, we’ll also be removing support for OCSP Must Staple. CRLs have wide browser support and can provide privacy benefits to all sites, without requiring special web server configuration. Thanks to all our subscribers who have helped with the OCSP Must Staple experiment.
If you are not certain whether you are using OCSP Must Staple, you can check this list of hostnames and certificate serials (11.1 MB, .zip).
As of January 30, 2025, issuance requests that include the OCSP Must Staple extension will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension.
As of May 7, all issuance requests that include the OCSP Must Staple extension will fail, including renewals. Please change your ACME client configuration to not request the extension.
Post Syndicated from Prasad Rao original https://aws.amazon.com/blogs/aws/introducing-buy-with-aws-an-accelerated-procurement-experience-on-aws-partner-sites-powered-by-aws-marketplace/
Today, we are announcing Buy with AWS, a new way to discover and purchase solutions available in AWS Marketplace from AWS Partner sites. You can use Buy with AWS to accelerate and streamline your product procurement process on websites outside of Amazon Web Services (AWS). This feature provides you the ability to find, try, and buy solutions from Partner websites using your AWS account
AWS Marketplace is a curated digital store for you to find, buy, deploy, and manage cloud solutions from Partners. Buy with AWS is another step towards AWS Marketplace making it easy for you to find and procure the right Partner solutions, when and where you need them. You can conveniently find and procure solutions in AWS Marketplace, through integrated AWS service consoles, and now on Partner websites.
Accelerate cloud solution discovery and evaluation
You can now discover solutions from Partners available for purchase through AWS Marketplace as you explore solutions on the web beyond AWS.
Look for products that are “Available in AWS Marketplace” when browsing on Partner sites, then accelerate your evaluation process with fast access to free trials, demo requests, and inquiries for custom pricing.
For example, I want to evaluate Wiz to see how it can help with my cloud security requirements. While browsing the Wiz website, I come across a page where I see “Connect Wiz with Amazon Web Services (AWS)”.
I choose Try with AWS. It asks me to sign in to my AWS account if I’m not signed in already. I’m then presented with a Wiz and AWS co-branded page for me to sign up for the free trial.
The discovery experience that you see will vary depending on type of the Partner website you’re shopping from. Wiz is an example of how Buy with AWS can be implemented by an independent software vendor (ISV). Now, let’s look at an example of an AWS Marketplace Channel Partner, or reseller, who operates a storefront of their own.
I browse to the Bytes storefront with product listings from AWS Marketplace. I have the option to filter and search from the curated product listings, which are available in AWS Marketplace, on the Bytes site.
I choose View Details for Fortinet and see an option to Request Private Offer from AWS.
As you can tell, on a Channel Partner site, you can browse curated product listings available in AWS Marketplace, filter products, and request custom pricing using your AWS account directly from their website.
Streamline product procurement on AWS Partner sites
I had a seamless experience using Buy with AWS to access a free trial for Wiz and browse through the Bytes storefront to request a private offer.
Now I want to try Databricks for one of the applications I’m building. I sign up for a Databricks trial through their website.
I chose Upgrade and see Databricks is available in AWS Marketplace, which gives me the option to Buy with AWS.
I choose Buy with AWS, and after I sign in to my AWS account, I land on a Databricks and AWS Marketplace co-branded procurement page.
I complete the purchase on the co-branded procurement page and continue to set up my Databricks account.
As you can tell, I didn’t have to navigate the challenge of managing procurement processes for multiple vendors. I also didn’t have to speak with a sales representative or onboard a new vendor in my billing system, which would have required multiple approvals and delayed the overall process.
Access centralized billing and benefits through AWS Marketplace
Because Buy with AWS purchases are transacted through and managed in AWS Marketplace, you also benefit from the post-purchase experience of AWS Marketplace, including consolidated AWS billing, centralized subscription management, and access to cost optimization tools.
For example, through the AWS Billing and Cost Management console, I can centrally manage all my AWS purchases, including Buy with AWS purchases, from one dashboard. I can easily access and process invoices for all of my organization’s AWS purchases. I also need to have valid AWS Identity and Access Management (IAM) permissions to manage subscriptions and make a purchase through AWS Marketplace.
AWS Marketplace not only simplifies my billing but also helps in maintaining governance over spending by helping me manage purchasing authority and subscription access for my organization with centralized visibility and controls. I can manage my budget with pricing flexibility, cost transparency, and AWS cost management tools.
Buy with AWS for Partners
Buy with AWS enables Partners who sell or resell products in AWS Marketplace to create new solution discovery and buying experiences for customers on their own websites. By adding call to action (CTA) buttons to their websites such as “Buy with AWS”, “Try free with AWS”, “Request private offer”, and “Request demo”, Partners can help accelerate product evaluation and the path-to-purchase for customers.
By integrating AWS Marketplace APIs, Partners can display products from the AWS Marketplace catalog, allow customers to sort and filter products, and streamline private offers. Partners implementing Buy with AWS can access AWS Marketplace creative and messaging resources for guidance on building their own web experiences. Partners who implement Buy with AWS can access metrics for insights into engagement and conversion performance.
The Buy with AWS onboarding guide in the AWS Marketplace Management Portal details how Partners can get started.
Learn more
Visit the Buy with AWS page to learn more and explore Partner sites that offer Buy with AWS.
To learn more about selling or reselling products using Buy with AWS on your website, visit:
– Prasad