Прикольная история успеха, как стартанув с "нуля" студент смог заработать денег
I Made a Million Dollar Product from My Dorm Room
https://nick.winans.io/blog/nice-nano/
ЗЫ Это мог быть ваш четверговый проект, но в этот четверг никто не пришёл 🌝
https://xn--r1a.website/tech_b0lt_Genona/4983
This post shares the story of the nice!nano; a wireless, Pro Micro-compatible microcontroller board I made in my freshman year of college. The nice!nano powers tens of thousands of keyboards, has inspired many, and changed my life.
Over my first winter break in college, I created what I called the Dissatisfaction65, a wireless 65% keyboard inspired by the Satisfaction75. I don’t remember exactly why, but I wanted to try making a DIY wireless keyboard after having made a few wired ones. The Adafruit 32u4 Bluefruit LE microcontroller was used to accomplish wireless since the open-source QMK keyboard firmware supported Bluetooth with this specific board. The project looked great in the end, but its performance was awful. The typing latency was nearly unusable, and it only lasted a few days on battery even with a huge battery inside.
. . .
The weekend (yes, the whole thing was designed in a weekend) I created the nice!nano.It was just me, KiCad, Nordic’s Infocenter2, nRFMicro wiki, and the Adafruit nRF52840 Feather schematic. I put together the schematic and BOM, laid out the PCB, and routed (and re-routed) the connections. On the other side I came out with the thinnest Pro Micro compatible nRF52840 based board.
. . .
Over the next week I created a name and found my PCB assembler. The name is based on my online username, “Nicell”. I wanted to continue the spirit of metric naming of the Pro Micro and came up with “nice!nano”.After reaching out to a few assemblers, the cheapest option for producing five was about $100.
. . .
As a college student, I didn’t have the money to bank roll a purchase of 1,000 nice!nanos, so I ran a group buy pre-purchase. At the time I had set a minimum purchase amount of 200 pieces for the order to go through and a maximum of 1,000 because I didn’t think I could handle more than that.
. . .
Within just seven hours all 1,000 nice!nanos had been sold, ending the group buy. In the next two months I got all the product in and shipped out the 400+ unique orders with the help of my family.
. . .
The million dollar product#
Ok, so the title is a bit of click-bait, but if you made it this far, I suppose it worked. The nice!nano might have been designed in my dorm room, but this was a multi-year journey. To date, over 50,000 nice!nanos have been sold at various online retailers around the world representing over a million dollars in sales. It’s hard to wrap my head around still, and I’m extremely grateful.
I Made a Million Dollar Product from My Dorm Room
https://nick.winans.io/blog/nice-nano/
ЗЫ Это мог быть ваш четверговый проект, но в этот четверг никто не пришёл 🌝
https://xn--r1a.website/tech_b0lt_Genona/4983
👍10❤2🥴2💊2😁1🥱1
Поздравляю @aenix_io и @cozystack/@cozystack_ru
Ænix, основной разработчик open source-платформы Cozystack, привлек 300 тысяч долларов на стадии seed
https://habr.com/ru/companies/aenix/news/899586/
Бизнес-модель Ænix заключается в продаже подписки на Ænix Enterprise for Cozystack, в которую входят техническая поддержка с гарантиями по SLA, сопровождение платформы, professional services, а также энтерпрайзная функциональность (например, White Labeling и система биллинга).
Андрей Квапил, CEO Ænix: «Мы долго искали и тщательно выбирали инвестора — команду, которая понимает ценность того, что мы делаем, у которой есть опыт успешного инвестирования в похожие проекты, связи с институциональными инвесторами и потенциальными клиентами, а также опыт консультирования стартапов. И мы рады, что нашим партнером на этом пути стала именно команда Prospective Technologies. Кроме того, я благодарен всей нашей команде, ребятам из Ænix, внешнему сообществу пользователей и контрибьюторов, а также клиентов, которые поверили в нас и оказали серьезную поддержку».
Сергей Негодяев, Управляющий Партнер, Prospective Technologies: «Ænix решает важнейшую задачу для компаний, которым необходим контроль над своей инфраструктурой без потери гибкости современного облака. Вклад Cozystack в CNCF демонстрирует их приверженность инновациям с открытым исходным кодом, и мы рады поддержать их путь».
Ænix, основной разработчик open source-платформы Cozystack, привлек 300 тысяч долларов на стадии seed
https://habr.com/ru/companies/aenix/news/899586/
🎉33👍9🔥5🤡3👎1😁1
Forwarded from Simple Engineer Notes
🛠 VmWare & Hardware version debug
Jenkins runs a powershell script and it creates a VM. Normally it works, but this morning I got this:
The first idea was that something has been changed in the powershell wrapper. But with the terraform I got more a less the same error. It was complaning about unsupported guest ID. In packer we explicitly specify rhel8_64Guest, but just in case I also decided to specify it in terraform https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/virtual_machine#guest_id-1 and got different errors:
rhel8_64Guest:
rockylinux_64Guest:
However in the docs https://knowledge.broadcom.com/external/article/321876/determine-the-guest-os-from-a-vm-configu.html both of them exist. The next idea was to epoxrt list of guest IDs:
and again... both of them exist. Also the windows VM were created without any problems. However, my workmate spotted that the different hardware version is available for customezation in web UI. I also found it in the doc https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/virtual_machine#hardware_version-1. So, If I set the
What happens?
1. We used to have the VM hardware compatibility set to version 19. And the templates we created used to be detected as RHEL8. And compatibility for version 19 supported RHEL 8.
2. Weekly template rebuild happens
3. what's happening right now?
- The template is still defined as RHEL 8
- During deployment VMWare automatically detects it as Rocky Linux 8
- Vmware sets the Guest OS to
- rockylinux_64Guest is not compatible with VM version 19
- When the VM is startted it get the error
4. The compat level in packer template was increased to 21 and rebuilt.
Why it happens?
1. The first idea was that VMWare tools was updated(we are installing the latest one). but it's the same
2. The Vcenter version is also the same.
3. The code is also the same.
4. Something else has been updated inside the VM template(we also install all updates) like firmware but i've not find the diff yet. also the kernel https://oraclelinux.pkgs.org/8/ol8-baseos-latest-x86_64/kernel-4.18.0-553.46.1.el8_10.x86_64.rpm.html was suspicious but I found nothing interesting in the release notes
5. i also upgraded rocky 8.6->8.10 at a test VM just to exclude the changes in the
so.. I don't know why.. wip..
#vmware #debug #terraform
Jenkins runs a powershell script and it creates a VM. Normally it works, but this morning I got this:
Virtual Machine [xxx] does not exist
Importing new Virtual Machine
New-VM : 4/4/2025 9:55:27 AM New-VM An invalid argument "configSpec.guestId" was specified.
At C:\...\powershell\commonScripts\Initialize-VM.ps1:247 char:14
+ ... $newVM = New-VM -Name $VMName -ContentLibraryItem $templateObj -Da ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-VM], ViError
+ FullyQualifiedErrorId : ViCore_VMServiceImpl_DeployFromLibraryItem_ViNetException,VMware.VimAutomation.ViCore.Cm dlets.Commands.NewVM
The first idea was that something has been changed in the powershell wrapper. But with the terraform I got more a less the same error. It was complaning about unsupported guest ID. In packer we explicitly specify rhel8_64Guest, but just in case I also decided to specify it in terraform https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/virtual_machine#guest_id-1 and got different errors:
rhel8_64Guest:
│ Error: deploy error: An invalid argument "configSpec.guestId" was specified.
│
│ with module.Personal.vsphere_virtual_machine.ld-lgonchar-2,
│ on modules/Personal/ld-lgonchar-2.example.local.tf line 2, in resource "vsphere_virtual_machine" "ld-lgonchar-2":
│ 2: resource "vsphere_virtual_machine" "ld-lgonchar-2" {
rockylinux_64Guest:
│ Error: cannot find OS family for guest ID "rockylinux_64Guest": could not find guest ID "rockylinux_64Guest"
│
│ with module.Personal.vsphere_virtual_machine.ld-lgonchar-2,
│ on modules/Personal/ld-lgonchar-2.example.local.tf line 2, in resource "vsphere_virtual_machine" "ld-lgonchar-2":
│ 2: resource "vsphere_virtual_machine" "ld-lgonchar-2" {
However in the docs https://knowledge.broadcom.com/external/article/321876/determine-the-guest-os-from-a-vm-configu.html both of them exist. The next idea was to epoxrt list of guest IDs:
[VMware.Vim.VirtualMachineGuestOsIdentifier].GetEnumValues()
...
rhel8_64Guest
...
rockylinux_64Guest
almalinux_64Guest
and again... both of them exist. Also the windows VM were created without any problems. However, my workmate spotted that the different hardware version is available for customezation in web UI. I also found it in the doc https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/virtual_machine#hardware_version-1. So, If I set the
hardware_version param to 21 it works because rockylinux_64Guest is introduced.What happens?
1. We used to have the VM hardware compatibility set to version 19. And the templates we created used to be detected as RHEL8. And compatibility for version 19 supported RHEL 8.
2. Weekly template rebuild happens
3. what's happening right now?
- The template is still defined as RHEL 8
- During deployment VMWare automatically detects it as Rocky Linux 8
- Vmware sets the Guest OS to
rockylinux_64Guest.- rockylinux_64Guest is not compatible with VM version 19
- When the VM is startted it get the error
The guest operating system 'rockylinux_64Guest' is not supported.4. The compat level in packer template was increased to 21 and rebuilt.
Why it happens?
1. The first idea was that VMWare tools was updated(we are installing the latest one). but it's the same
2. The Vcenter version is also the same.
3. The code is also the same.
4. Something else has been updated inside the VM template(we also install all updates) like firmware but i've not find the diff yet. also the kernel https://oraclelinux.pkgs.org/8/ol8-baseos-latest-x86_64/kernel-4.18.0-553.46.1.el8_10.x86_64.rpm.html was suspicious but I found nothing interesting in the release notes
5. i also upgraded rocky 8.6->8.10 at a test VM just to exclude the changes in the
/etc/redhat-releaseso.. I don't know why.. wip..
#vmware #debug #terraform
👍2🔥2
Поехали!
👍37🎉16😭6🔥4🥱3🤡2👎1🖕1
Зачем эти полумеры? Надо ставить 1 день, а потом двигаться к новому сертификату на каждый коннект
Максимальное время жизни TLS-сертификатов сократят с 398 до 47 дней
https://www.opennet.ru/opennews/art.shtml?num=63069
Оригинал
https://mstdn.social/@jschauma/114325519681641946
Участники ассоциации CA/Browser Forum, являющейся площадкой для координации совместной работы производителей браузеров и удостоверяющих центров, проголосовали за сокращение максимального времени жизни TLS-сертификатов. Максимальное время действия TLS-сертификатов будет сокращено с 398 до 47 дней, если в дальнейшем CA/Browser Forum не пересмотрит принятое решение.
. . .
Изменение намерены продвигать постепенно: начиная с 15 марта 2026 года максимальный срок действия TLS-сертификатов будет уменьшен до 250 дней, с 15 марта 2027 года - до 100 дней, а с марта 2029 года - до 47 дней.
. . .
За новое сокращение времени жизни TLS-сертификатов проголосовали 29 участников, 6 воздержались и никто не отдал голос против. Участники, проголосовавшие "за": Apple, Google, Microsoft, Mozilla, Amazon, Asseco Data Systems SA (Certum), Buypass AS, Certigna (DHIMYOTIS), Certinomis, DigiCert, Disig, D-TRUST, eMudhra, Fastly, GlobalSign, GoDaddy, HARICA, iTrusChina, Izenpe, NAVER Cloud Trust Services, OISTE Foundation, Sectigo, SHECA, SSL.com, SwissSign, Telia Company, TrustAsia, VikingCloud, Visa. Участники, которые воздержались: Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, TWCA.
. . .
Предполагается, что генерация короткодействующих сертификатов позволит быстрее внедрять новые криптоалгоритмы в случае выявления уязвимостей в ныне действующих, а также сократит угрозы безопасности.
. . .
Кроме того, короткодействующие сертификаты станут стимулом для внедрения автоматических систем управления сертификатами, избавленными от человеческого фактора. При этом, изжитие практики ручного обновления сертификатов может привести и к негативным последствиям. Отмечается, что некоторые устройства, допускающие загрузку сертификатов только в ручном режиме, могут остаться с недействительными сертификатами из-за сложности организации ручного обновления каждые полтора месяца. Изменение также может негативно повлиять на бизнес удостоверяющих центров, не предоставляющих API для автоматического получения сертификатов.
Максимальное время жизни TLS-сертификатов сократят с 398 до 47 дней
https://www.opennet.ru/opennews/art.shtml?num=63069
Оригинал
https://mstdn.social/@jschauma/114325519681641946
🤣32🥴10🍌5👍4👎1🤬1💊1
После последней нашей публикации про «отечественную» микросхему Flash памяти GSN2516Y якобы разработанную в GS Group мы получили достаточно большой фидбэк от наших читателей. И один из них сказал, что может переслать нам счетчик электроэнергии в котором стоит эта микросхема.
. . .
Что же получается у нас в результате?
Даже если предположить, что все остальные требования 719 ПП РФ компанией Энергомера выполнены:
- Печатные платы сделаны в России (+ 12 баллов)
- Весь счетчик собран в России (+15 баллов)
- Все корпусные детали сделаны в России (+ 15 баллов)
- Реле нагрузки сделано в России (+ 5 баллов) (на самом деле с ним мы еще не разобрались, но любые сомнения в пользу подозреваемого)
- Измерительный шунт сделан в России (+ 5 баллов) (с ним мы тоже еще не разобрались, но любые сомнения в пользу подозреваемого)
- Датчик магнитного поля сделан в России (+ 3 балла) (мы пока его не нашли, возможно его и нет, но опять сомнения в пользу подозреваемого)
- Микросхемы питания (+ 5 баллов) (мы пока не нашли явно российских, возможно там и затесалась какая либо LDOшка от Микрона)
- Микросхема памяти от GSnano (+12 баллов) (при всех наших сомнениях и особых мнениях)
- Микросхема АЦП (0 баллов из 13)
- Центральный микроконтроллер (0 баллов из 28)
- Интерфейсные микросхемы (0 баллов из 12)
В итоге получается, что счетчик электроэнергии Энергомера СЕ207 R7 набирает максимум 72 балла, но никак не 113 или даже заявленные 117 баллов в реестре. Таким образом, под большим сомнением теперь статус отечественности на этот счетчик, и как следствие возникают вопросы к достоверности победившей заявки в тендере Татэнергосбыта на сумму 992 449 333,55 рублей. Татэнергосбыт хотел отечественные счетчики с максимальными баллами, а получил похоже перемаркированные китайские микросхемы.
Наше расследование: ищем отечественные микросхемы в «отечественных» счетчиках электроэнергии
https://habr.com/ru/articles/899116/
Предыдущие посты от них на эту же тему
Наше расследование: мониторы LightCom, блогеры и все все все…
https://habr.com/ru/articles/810835/
Наше расследование: Блогеры и все все все… Часть 2
https://habr.com/ru/articles/819237/
Спасибо подписчику за ссылку
👍30🤡12🔥4💔2😨2🐳1
TARIFF is a fantastic tool that lets you impose import tariffs on Python packages. We're going to bring manufacturing BACK to your codebase by making foreign imports more EXPENSIVE!
How It Works
When you import a package that has a tariff:
1. TARIFF measures how long the original import takes
2. TARIFF makes the import take longer based on your tariff percentage
3. TARIFF announces the tariff with a TREMENDOUS message
Example Output
https://github.com/hxu296/tariff
import tariff
# Set your tariff rates (package_name: percentage)
tariff.set({
"numpy": 50, # 50% tariff on numpy
"pandas": 200, # 200% tariff on pandas
"requests": 150 # 150% tariff on requests
})
# Now when you import these packages, they'll be TARIFFED!
import numpy # This will be 50% slower
import pandas # This will be 200% slower
How It Works
When you import a package that has a tariff:
1. TARIFF measures how long the original import takes
2. TARIFF makes the import take longer based on your tariff percentage
3. TARIFF announces the tariff with a TREMENDOUS message
Example Output
JUST IMPOSED a 50% TARIFF on numpy! Original import took 45000 us, now takes 67500 us. American packages are WINNING AGAIN! #MIPA
https://github.com/hxu296/tariff
😁73🤡12🔥4❤3😢2🗿2👌1🤣1
Инструменты программирования с поддержкой искусственного интеллекта (ИИ) всё больше влияют на разработку программного обеспечения и приводят к проблеме в безопасности: генерации несуществующих имён пакетов. ИИ модели как коммерческие, так и открытые, иногда предлагают код с указанием пакетов, которых не существует. Согласно недавним исследованиям, это происходит в 5.2% случаев у коммерческих моделей и в 21.7% - у открытых моделей.
Обычно это приводит лишь к ошибке установки, но злоумышленники начали использовать эти "галлюцинации" в своих целях, размещая вредоносные пакеты под этими вымышленными именами в публичных репозиториях, таких как PyPI или NPM. Такая стратегия превращает галлюцинации ИИ в новый вектор атак на цепочки поставок ПО.
Постоянно повторяющиеся имена особенно привлекательны для атак. Эта стратегия, похожая на "тайпсквоттинг", была названа Сетом Майклом Ларсоном из Фонда Python "слопсквоттингом" - от слова slop (бесполезный выход ИИ).
Руководитель компании Socket Феросс Абухадиджех (Feross Aboukhadijeh) указывает на культурный сдвиг в сообществе разработчиков в сторону "вaйб-кодинга" (vibe coding) - когда ИИ подсказки копируются без проверки. Это поведение повышает риск установки вредоносных пакетов. Иногда разработчики даже не замечают, что пакет не существует - особенно если его имя уже занято злоумышленником. Такие вредоносные пакеты часто выглядят вполне убедительно: с фальшивыми документациями, поддельными репозиториями на GitHub и даже блогами, создающими видимость легитимности.
Ситуацию усугубляет тот факт, что ИИ-системы подтверждают галлюцинации друг друга. Например, Gemini от Google уже предлагал пользователям вредоносные пакеты, описывая их как надёжные и поддерживаемые — просто повторяя информацию из поддельного README.
Отмечается случай с киберпреступником по имени "_Iain", который на форуме в даркнете делился методами создания ботнета на основе блокчейна, используя тысячи тайпсквоттинг-пакетов в NPM. С помощью ChatGPT он автоматически сгенерировал множество имён, похожие на реальные.
ИИ как новый вектор атаки на разработчиков ПО
https://www.opennet.ru/opennews/art.shtml?num=63062
Оригинал
The Rise of Slopsquatting: How AI Hallucinations Are Fueling a New Class of Supply Chain Attacks
https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks
Ссылка на исследование (PDF скину в комменты)
https://arxiv.org/pdf/2406.10279
🔥15👍6🤣3