1 pontos por GN⁺ 2024-11-08 | 1 comentários | Compartilhar no WhatsApp
  • Desenvolvedores de sistemas operacionais embarcados e de tempo real agora podem experimentar o QNX SDP 8.0 gratuitamente para fins de estudo, hobby e prototipagem, reduzindo a barreira de entrada antes mais voltada ao uso comercial
  • Os usuários precisam enviar o formulário de licença com uma conta myQNX e, após o processamento da solicitação, recebem uma licença de software QNX para uso não comercial
  • O pacote inclui QNX SDP 8.0, QNX Developer Desktop e QNX Hypervisor, cobrindo desde o aprendizado do sistema operacional até desenvolvimento self-hosted e testes de virtualização
  • Como recursos iniciais, são oferecidos o Quick Start Guide, a imagem do QNX 8.0 para Raspberry Pi, os vídeos do QNX Everywhere e o Self-Hosted Developer Desktop Guide
  • A licença gratuita é limitada a educação, projetos pessoais e aprendizado de RTOS; para avaliação ou desenvolvimento com fins comerciais, é necessário solicitar uma licença de avaliação separada de 30 dias

Disponibilização de ambiente de desenvolvimento QNX para uso não comercial

  • QNX Everywhere é um programa que permite a estudantes, desenvolvedores hobbyistas e prototipadores usar o software QNX gratuitamente para fins não comerciais
  • O que é oferecido inclui o sistema operacional de próxima geração da QNX, ferramentas de desenvolvimento e recursos de tempo real, que podem ser usados em aprendizado, experimentação e criação de projetos embarcados de alto desempenho
  • Os números divulgados incluem 15K+ downloads de licenças do QNX Everywhere, 6K+ alunos registrados em treinamentos online e 100+ instituições acadêmicas parceiras

Fluxo de solicitação da licença

  • Para obter a licença não comercial, é necessário ter uma conta myQNX
    • Se você já tiver uma conta, basta fazer login
    • Se estiver usando QNX pela primeira vez, crie uma conta myQNX
  • Após o login, inicie a solicitação preenchendo os dados de licença no formulário de licença do QNX Everywhere
  • Quando o processamento da solicitação for concluído, você receberá uma licença de software QNX para uso não comercial
  • A licença pode levar até 1 hora após a solicitação para aparecer no perfil myQNX

Plataformas e ferramentas incluídas

  • QNX SDP 8.0 é a plataforma básica de desenvolvimento para SoCs de próxima geração
    • Inclui o sistema operacional QNX de próxima geração
    • Destaca uma arquitetura projetada para aproveitar futuros avanços em silício
    • Tem como objetivo oferecer desempenho consistente em tempo real para sistemas com uso intensivo de computação em todo o universo de IoT
    • Inclui toolchain atualizada, novos utilitários de depuração e profiling, além de utilitários open source
  • O QNX Everywhere inclui acesso aos seguintes itens
    • QNX SDP 8.0: plataforma RTOS de microkernel de alto desempenho e pronta para segurança
    • QNX Developer Desktop: desktop self-hosted para compilar aplicações no QNX OS 8.0
    • QNX Hypervisor: hipervisor determinístico para sistemas de criticidade mista

Educação, comunidade e open source

  • A QNX oferece cursos online gratuitos para desenvolvedores do QNX OS
  • Os desenvolvedores podem se conectar com engenheiros da QNX e com a comunidade online de desenvolvedores para resolver problemas, discutir ideias e colaborar em projetos open source
  • Como é um sistema operacional compatível com POSIX, uma parte significativa dos softwares para sistemas operacionais POSIX pode ser compilada para QNX com poucas ou nenhuma modificação
  • A QNX publica o código-fonte de ports open source conforme as licenças originais e mantém os ports disponíveis para desenvolvedores no GitHub repository
  • Informações sobre ports, nível de testes e detalhes de hospedagem podem ser vistas no Open-Source Dashboard

Primeiros passos com documentação e imagem para Raspberry Pi

  • A documentação do QNX Everywhere fornece as ferramentas e orientações necessárias para criar desde a primeira aplicação até soluções avançadas em QNX
  • Os recursos oferecidos são os seguintes
  • Usuários do Raspberry Pi 5 podem gravar e usar a imagem pronta do QNX SDP 8.0
    • A imagem inclui vários aplicativos de demonstração open source
    • Os aplicativos de demonstração podem ser clonados, modificados e recompilados

Condições de uso e exclusões

  • A licença gratuita é destinada a usuários individuais não comerciais do QNX Software Development Platform 8.0
  • Os usos permitidos incluem fins educacionais, projetos pessoais e atividades sem geração de receita nem operação comercial
  • O uso não comercial inclui ambientes acadêmicos, desenvolvedores hobbyistas e pessoas aprendendo sobre sistemas operacionais de tempo real
  • Avaliação ou desenvolvimento para fins comerciais não estão incluídos
    • Atividade comercial inclui geração de receita ou operação de negócios
    • A licença de avaliação comercial de 30 dias deve ser solicitada separadamente
  • O QNX SDP 7.1 não está incluído neste programa
    • O QNX SDP 8.0 é oferecido como plataforma de software de próxima geração voltada a SoCs com 4 ou mais núcleos de CPU

Instalação múltipla em instituições de ensino

  • Para configurar várias estações de trabalho em laboratórios ou salas de aula, é possível obter licença multiusuário por meio do programa QNX in Education
    • Entre os itens cobertos estão o QNX Software Development Platform 8.0 e o QNX Software Development Platform 7.1
  • Quando for instalar apenas uma instância por vez, é recomendável usar a licença do QNX Everywhere

Solução de problemas de conta e licença

  • Se houver problemas de login após registrar uma nova conta myQNX, entre em contato com myqnx@blackberry.com
  • O status da licença e da distribuição do produto pode ser consultado e aceito no myQNX License Manager
  • Na seção Registered Products do perfil da conta myQNX, são exibidos a chave de licença, número de série, certificado de licença e gerenciador de licenças de cada produto distribuído
  • Para baixar o QNX Software Center, o usuário myQNX precisa ter uma licença de produto QNX atribuída

1 comentários

 
GN⁺ 2024-11-08
Opiniões do Hacker News
  • Seria ótimo se desse para confiar, mas o QNX já foi “aberto” duas vezes no passado e depois fechado de novo.
    Antes da primeira retirada, projetos open source costumavam incluir QNX como alvo de build, e era possível ter suporte a alvos para Firefox e Eclipse no QNX, além de builds do GCC e das ferramentas de linha de comando GNU.
    Também havia um ambiente de desktop chamado Photon, que usei por 3 anos como desktop principal quando construímos um veículo para o DARPA Grand Challenge.
    Mas, depois que a Harman adquiriu a QNX em 2004, tudo isso desapareceu; em 2007 o código-fonte foi aberto novamente, a ponto de ser possível olhar dentro do microkernel e compilá-lo, mas não era uma licença pública.
    Quando a RIM adquiriu a QNX em 2010, fechou o código-fonte sem nenhum aviso; todo o desenvolvimento open source relacionado ao QNX foi interrompido, e a comunidade também perdeu a confiança.
    Os termos contratuais também são um problema: em http://www.qnx.com/download/feature.html?programid=51624 está escrito “TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party”, o que significa que a QNX pode cortar o acesso a qualquer momento.
    Se a QNX estiver falando sério, parece correto seguir uma licença no estilo Unreal Engine: baixar o código-fonte, usar à vontade, grátis até o produto atingir US$ 1 milhão em receita, e depois a Epic recebe 5% de royalties: https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
    A pirataria também não é um grande problema, porque, quando um jogo começa a gerar receita significativa, ele fica visível o bastante para que a equipe de licenciamento fique sabendo.
    Se querem aumentar a adoção do QNX, seria bom levar a tabela de condições da Epic ao jurídico e à diretoria e comparar o crescimento da receita do Unreal Engine com o QNX.
    Como eu disse tempos atrás a um representante de vendas da QNX, o problema da QNX não é pirataria, é que ela está sendo ignorada.

    • Em 2011, eu trabalhava em uma startup alemã adquirida pela RIM/Blackberry, e a empresa tentou fazer todos os funcionários assinarem um novo contrato que mantinha as funções e os salários existentes, mas tinha restrições de propriedade intelectual muito severas.
      Toda atividade open source era proibida, e muitos de nós, na época, participávamos ativamente de open source. Eu também já tinha trabalhado na Eclipse Foundation.
      Um amigo que escrevia romances foi informado de que precisaria de autorização por escrito toda vez que postasse ou publicasse qualquer texto.
      Mesmo com uma tradução para o alemão anexada, engenheiros alemães foram pressionados a assinar um contrato cuja língua juridicamente vinculante era o inglês, e no fim muitos de nós simplesmente foram embora.
      O que mais me marcou foi a equipe de transição vinda do Canadá dizer que “os funcionários da RIM trabalham em masmorras escuras de concreto, então vocês têm muita sorte por poderem continuar usando o ótimo escritório de Munique”.
      No DNA daquela empresa, uma abordagem aberta parecia algo completamente estranho, e eu não confiaria nem um pouco.
    • Uma opção seria licenciamento duplo com GPLv3 e licença comercial. O “3” em GPLv3 é importante.
      Desenvolvedores por hobby e projetos livres/open source usariam de bom grado um sistema operacional GPLv3, enquanto os grandes clientes comerciais tradicionais de automotivo e embarcados não vão querer as obrigações da GPLv3 de permitir que usuários instalem firmware customizado, então continuariam pagando.
      Poderia ser vantajoso para todos.
      Isto não é aconselhamento jurídico; cada um deve fazer sua própria interpretação da licença.
    • No DNA organizacional da RIM/Blackberry está enraizada uma experiência ruim para desenvolvedores.
      Tive uma longa conversa com engenheiros antes do BB10 ser lançado e, se bem me lembro, para acessar todo o SDK do Blackberry era preciso se candidatar e também assinar um NDA.
      Enquanto isso, Android e iOS já estavam a todo vapor, e venceu quem priorizou plataformas em que era fácil escrever apps.
      A Blackberry parece organizacionalmente incapaz de lidar com a comunidade e com esse tipo de relação. Uma mentalidade de operadora, de “nós contra eles”, está no topo da organização e, explícita ou implicitamente, vai se infiltrando para baixo.
    • Antes de 2004, o QNX ainda poderia ter ocupado uma posição relevante. Era uma época em que usuários e desenvolvedores experimentavam sistemas operacionais, e ele poderia atrair gente suficiente para criar um nicho até no desktop.
      Depois que o BeOS fracassou, eu brinquei com o QNX e desenvolvi para ele, e gostei tanto que o usei em tempo integral na minha máquina principal de desenvolvimento.
      Mas, quando ele foi fechado, me queimei feio, e desde então não mexo mais em nenhuma plataforma de desenvolvimento fechada.
      Olhando a licença agora, nada mudou, e hoje, fora seus mercados existentes, o QNX se tornou em grande parte irrelevante.
      Escolher QNX hoje parece uma tolice. Agora há boas alternativas, e todas têm licenças abertas.
    • Também fico curioso para saber quantas aplicações realmente precisam de resposta em tempo real mais forte que a do Linux.
      Agora também existe https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o...
      Usar Linux dispensa discussões de licenciamento e elimina a preocupação de levar uma rasteira de repente e ver tudo ser fechado.
      A proibição de uso comercial é horrível. Estou passando por algo parecido agora com o ArangoDB: o produto é bom, mas não tenho orçamento para uma instância em nuvem gerenciada por eles nem para discutir uma licença comercial com o time de vendas.
      Uso em vários sistemas, e um deles já chegou a cerca de 80% do tamanho de banco de dados “grande demais para usar de graça”, mas não sei se o destino dele será virar open source, virar produto ou virar um sistema que gera dinheiro diretamente.
      Por isso, o caminho curto no momento é migrar para PostgreSQL, não conversar com pessoas que talvez não permitam meu modelo de negócios.
  • Para ver diretamente os termos para desenvolvedores vinculados ao uso não comercial do QNX 8.0, é aqui: https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
    Não é aconselhamento jurídico, nem uma análise abrangente ou resumo interpretativo desta licença. Antes de agir com base no conteúdo abaixo, você deve obter orientação profissional de um advogado
    Os termos começam com uma cláusula dizendo que o usuário não teve oportunidade de revisar e concordar antes de vincular a si mesmo, sua empresa ou instituição, o que nos EUA parece que poderia até invalidar o documento inteiro; então é mais seguro revisar com um advogado antes de usar
    No meio acadêmico, apenas alunos e docentes da instituição são elegíveis, e o uso desta licença pode ser visto, do ponto de vista do jurídico, como a assinatura de um contrato vinculante em nome do empregador
    É preciso verificar se você não corre o risco de ser responsabilizado por contribuidores open source, ou de ser demitido por se apresentar indevidamente como signatário autorizado da instituição
    Usuários de nuvem, pelos termos, ficam limitados à AWS; usar no GCP, Heroku ou em outras instâncias de servidor que não estejam sob o controle de um contrato pessoal pode gerar cobrança de taxas de licença
    O “Open Source” permitido aqui é apenas o da definição da OSI; portanto, quem distribui software sob uma licença não comercial restritiva não pode usar a licença não comercial do QNX
    A cláusula de “alto risco” proíbe o desenvolvimento de aplicações que possam causar danos à sociedade, portanto apps sociais também podem ficar excluídos. Cuidado para não violar essa cláusula ao criar aplicações virais
    Coletam e armazenam todos os números de série identificáveis de todo hardware usado em relação a este produto
    A licença não comercial pode ser encerrada a qualquer momento, sem nenhuma condição, mesmo que você tenha cumprido fielmente os termos; nesse momento, talvez seja necessário fornecer uma “certificação” indefinida, a um custo desconhecido, de que todo o código QNX recebido foi apagado

    • Fico me perguntando desde quando app social virou alto risco. A cláusula de alto risco claramente mira aplicações com requisitos de segurança como IEC 61508 e ISO 26262
      Se um cliente do Twitter morrer, isso não fere nem mata ninguém
  • Com o Linux em tempo real já maduro, fico pensando se há algum projeto em que faça sentido usar QNX. Preciso mesmo me preocupar para tomar uma rasteira com uma mudança repentina de licença?
    Já usei QNX no passado por ser bonitinho e academicamente interessante
    Mas, da próxima vez que eu escolher um SoC para um projeto e o BSP que vem com ele, não vou procurar QNX. Provavelmente vou usar a distribuição FreeRTOS incluída ou instalar as ferramentas de build do Android e empurrar um APK para algum fork esquisito de Android
    Para automotivo ou médico a história é diferente, mas nesses setores os concorrentes continuam correndo atrás, e as mudanças de tempo real no Linux vão tornar a situação ainda mais difícil
    Não estamos mais em 2010. Há muitas opções, e enquanto o QNX ficou atrás de exigências de licenciamento obscuras e irritantes, dezenas de empresas desenvolveram alternativas. Algumas delas são bem grandes, e algumas até foram ao espaço
    Agora, para o QNX ser levado a sério, não basta “começar a abrir as portas do QNX como antes”
    Se não for open source completo também para uso comercial, não tenho interesse em usar. Se as ferramentas e o suporte a BSP valerem o tempo economizado, eu até poderia tolerar uma licença no estilo da Epic, mas não tenho interesse nenhum em pagar licença só para começar
    O produto virou commodity e agora é uma curiosidade. O único caminho para obter desenvolvimento ativo e adoção suficientes é virar um projeto de comunidade

    • O nome e a reputação ainda significam muito para algumas pessoas, e o fato de não precisarem aprender mais um sistema operacional também é importante
      Nem todo mundo se importa se é livre/open source, e não surpreende que pessoas diferentes pendam para lados diferentes nessas questões
    • Pode servir se você quiser conseguir um emprego em desenvolvimento de sistemas operacionais em tempo real e mostrar que leva essa área a sério
  • Entre os sistemas operacionais que usei no começo dos anos 2000, os únicos que fizeram um Pentium velho, single-core, de meados dos anos 90 parecer excelente e ágil foram QNX e BeOS
    Era muito melhor do que qualquer versão do Windows ou do Linux
    Em ambos os casos, acho que isso se devia principalmente ao scheduler e a uma stack multimídia muito melhor
    Sempre esperei que os sistemas operacionais do futuro tivessem essa sensação; o mais próximo talvez seja o iOS, e mesmo ele usa o truque de ficar matando processos. O futuro não é grande coisa

    • O BeOS era multithread “de modo geral”, o que, removendo o marketing, significava que o kernel não tinha um grande lock único. Isso porque ele foi projetado desde o início para sistemas multicore
      Os sistemas operacionais contemporâneos da época tinham um grande lock único
      Não lembro ao certo se o intervalo de preempção do BeOS era 750 ms ou 3 ms, mas era menor que os 20 ms do Linux e do Windows, depois 10 ms, e por isso provavelmente dava para sentir a diferença
      Décadas depois, a maioria dos sistemas operacionais alcançou um nível mais granular de locks no espaço do kernel, mas o intervalo de preempção ainda varia por causa do debate entre throughput e latência. Benchmarks de sistemas operacionais baseados em scripts medem o throughput total, não a responsividade da GUI
      Buffers de mídia que se beneficiam de tamanhos pequenos de buffer são um bom exemplo e, mesmo com menor throughput, músicos percebiam a melhor responsividade do BeOS, daí o apelido de “Media OS”
      Também no espaço da GUI, o servidor de apps do BeOS/Haiku oferece uma carga de trabalho mais distribuída do que outros ambientes de desktop. Cada janela recebe sua própria thread, o app também recebe sua própria thread, e o app e o servidor de aplicações têm uma thread por app e por janela, para não ficarem bloqueados esperando o parsing lento de mensagens de um app
      Por isso, até um app BeOS mínimo com uma janela gráfica de “Hello World” tem 4 threads. Mesmo que o app esteja ocupado, o resto do sistema ainda parece responsivo
      Em troca, há um custo de throughput e um custo de complexidade no desenvolvimento de apps, especialmente grande em apps portados
      O Haiku precisa ordenar mensagens do Qt/Gtk/toolkits de várias janelas em uma única fila de mensagens para evitar bugs de multithreading. Isso porque, no ambiente original, o loop de mensagens do app não era multithread
      Por causa dessa ordenação, no Haiku são necessárias chamadas extras de lock/unlock quando não seriam necessárias, por exemplo até em mensagens indo para a mesma janela
      Já apps nativos do Haiku são suaves como gelo. Aqui há uma captura de tela do editor de vídeo Medo, em que todas as janelas rodam em sua própria thread: https://raw.githubusercontent.com/smallstepforman/Medo/refs/...
      Em sistemas modernos, esse app é suave como gelo, quase uma heresia para um editor de vídeo. O app Haiku linkado foi escrito por mim
    • Sonho sinceramente com o dia em que computadores modernos deem boot rápido como um Commodore 128 antigo, reiniciem rápido e respondam com agilidade a cada tecla pressionada
    • Embora use truques, reconheço que ao menos tenta
      Abandonei o Android quando nem a Samsung parecia tentar melhorar seriamente a responsividade dos telefones
      É bom que a Apple valorize consistentemente a responsividade, e isso dá ao Google, à Samsung e à Microsoft um incentivo para arrumar seus produtos inchados
    • Como alguém que usou BeOS e OS/2 Warp, sinto falta da agilidade dos sistemas antigos. Nunca mexi diretamente no QNX
      Entre os sistemas operacionais atuais, qual chega mais perto dessa agilidade? Seria o Haiku OS?
      Uso bem um MacBook M1, mas às vezes sinto que não é o suficiente
    • Nunca rodei QNX, mas tive uma experiência parecida com o BeOS, em que um Pentium 90 parecia excelente
      Outro exemplo: o SGI IRIX tinha um scheduler excepcionalmente bom. Usei por um tempo uma máquina de 30 MHz, e o desktop era bem ágil
      Um dia compilei o AMP e coloquei uma lista de MP3s, em sua maioria de 192 kbps; a propósito, esse programa também conseguia decodificar 256 kbps sem engasgos
      Os arquivos estavam em um compartilhamento NFS e, ao rodar o gr_osview, o uso de CPU estava em 95%, mas o gerenciador de arquivos respondia e a música não engasgava
      Só o fato de decodificar MP3s de bitrate alto, acima de 192 kbps, em 30 MHz já era impressionante
      Manter a responsividade com um desktop X Window System completo aberto e reproduzindo arquivos de um compartilhamento NFS mostrava uma stack de rede leve e forte e um scheduler que funcionavam bem mesmo em hardware fraco
      Era IRIX 5.3, em um Indigo Elan
      Um amigo e eu gostávamos de sistemas operacionais, então rodamos BeOS em um Pentium 90 velho e, como dito acima, era ágil
      O Linux também teve seu papel. Depois de danos por água, aquele Pentium 90 deixou de ser estável e, por usar RAM sem paridade, o Windows NT ia ficando estranho aos poucos e entrava em blue screen repetidas vezes
      Por diversão, instalei o Red Hat 5.2 e ele rodou bem. Os logs do sistema registravam muitos itens a cada segundo, e dava para abrir um console X e simplesmente vê-los passando
      Essa máquina até serviu a página web da empresa por algumas semanas, só por diversão. Bons tempos
  • Acrescentando alguns detalhes, o código-fonte do QNX ficou acessível de 2007 até antes da aquisição pela RIM/Blackberry em 2010
    Há planos de voltar a oferecer acesso ao código-fonte do QNX?
    https://www.qnx.com/news/pr_2471_1.html

    • Não me peçam para prometer um cronograma, mas é claro que estamos indo em uma direção mais aberta e transparente
      Estamos ouvindo que isso é importante tanto para clientes quanto para a comunidade. Continuem acompanhando
  • A empresa anterior criava roteadores Active/Standby de alta disponibilidade para redes móveis e usava QNX como sistema operacional. Essa capacidade ainda impressiona
    Minha memória está meio vaga, mas rodávamos QNX no processador do plano de controle, e havia suporte nativo para iniciar processos em processadores remotos pela rede interna do roteador
    Ou seja, a comunicação entre processos de baixo nível podia usar IP, e o IPC do QNX era essencial para a funcionalidade de failover de alta disponibilidade
    O fato de os drivers de dispositivo serem processos em espaço de usuário, podendo ser reiniciados em caso de crash, também era excelente. Eu estava desenvolvendo um driver de rede, então às vezes isso realmente acontecia
    Também era melhor o fato de os dispositivos realmente aparecerem na árvore /dev/, ao contrário do Linux, em que dispositivos de rede são uma exceção e não aparecem direito na árvore /dev/
    Como curiosidade, uma vez tive um problema porque coloquei const por engano em um valor de retorno de IPC, e meu processo morria entre a função de IPC do QNX e a minha função
    Passei dias depurando, e o nível do depurador C/espaço de usuário que usávamos na época não conseguia pegar esse erro

    • Eu também trabalhei com roteadores para redes móveis, mas tudo rodava em Linux, inclusive o plano de controle
      As line cards também rodavam Linux, mas só programavam o ASIC conforme instruído pelo plano de controle
      Esses recursos não eram exatamente relevantes, e o IPC podia ser feito por HTTP ou da forma que você quisesse
    • Iniciar processos em processadores remotos pela rede interna já era possível no CP/NET(https://en.wikipedia.org/wiki/MP/M#CP/NET) ou no CP/J com JUNET([https://pl.wikipedia.org/wiki/JUNET_(CP/J))
  • @JohnAtQNX, dá para remover do site de downloads a restrição de que tudo exige uma conta, e também remover o mecanismo de licença do qcc?
    Isso ajudaria muito a incentivar desenvolvedores hobbistas a experimentar
    A receita provavelmente vem de contratos de licenciamento em volume, com uma estrutura de cobrança por dispositivo
    Se vocês irritarem as equipes de CI/CD que precisam dar suporte à linha de produtos QNX, essa fonte de receita fica em risco

    • Já discutimos internamente como tornar isso possível
      É bom ouvir a mesma coisa de fora; vou levar o assunto de volta à mesa e empurrar aos poucos
    • Pelo menos seria bom permitir login por outros serviços, como Google. Muitos sites já fazem isso
      Eu realmente detesto ter que criar mais um login novo toda vez que aparece alguma coisa nova
      O mesmo vale para feeds de notícias: quase metade dos sites de notícias diz ser “grátis”, mas exige login. Nesse caso é um pouco melhor, porque costuma ser fácil encontrar a mesma matéria em outro lugar
    • Exato. É mais provável que a pessoa vá para outro lugar com menos atrito
  • Ainda lembro de ter ficado impressionado com a demo do QNX em um único disquete, que incluía até navegador web. Era muito rápida
    Espero que dê certo. Só consigo imaginar o nó górdio que deve ser resolver todas as questões legais para realmente abrir alguma coisa
    Como outros disseram, depois de terem levado duas rasteiras, todos estão cautelosos, mas há muito do que gostar no QNX, então espero que desta vez ganhe tração

    • No fim dos anos 90, aquele disquete de demo do QNX era mágico. Mostrava como algo podia parecer rápido em um CPU 486 DX2 ou DX4 em comparação com Linux/Windows da época
      Desde então fiquei com uma impressão um tanto positiva do QNX, mas as mudanças de propriedade no meio do caminho e as alterações entre aberto/comercial sempre me mantiveram afastado
      Infelizmente, essa “abertura” também parece familiar, e acho que será revertida de novo a menos que surja uma comunidade livre e open source grande o bastante para manter um fork sob uma licença GPL realmente aberta
  • Gosto da tentativa ousada. Há muito tempo observo o QNX com interesse à distância, mas na maioria dos casos eu não era um usuário potencial
    Um bom próximo passo seria escolher tipos comuns de projetos de hobby e fazer uma série de posts no blog explicando como aplicar, nesses cenários, os pontos fortes do QNX

    • Eu também gostaria de ver textos assim. Tenho curiosidade sobre o QNX, mas, como alguém que mexe com robôs em casa, não tenho uma boa noção de que vantagem ele teria para mim
      Também trabalho em uma organização sem fins lucrativos que faz pesquisa de monitoramento costeiro, onde há algumas pessoas criando hardware customizado. Será que poderia ser útil para nós?
  • Nós, do Rizin, queremos melhorar o suporte a QNX no nosso framework livre e open source de engenharia reversa e depuração
    Já temos suporte[1][2][3][4], mas não conseguimos testá-lo de forma confiável
    Assim como o Windows oferece diretamente VMs limitadas para teste[5], seria ótimo se uma imagem QEMU viesse pronta
    [1] https://github.com/rizinorg/rizin/tree/dev/librz/bin/format/...
    [2] https://github.com/rizinorg/rizin/blob/dev/librz/bin/p/bin_q...
    [3] https://github.com/rizinorg/rizin/blob/dev/librz/debug/p/deb...
    [4] https://github.com/rizinorg/rizin/tree/dev/subprojects/rzqnx
    [5] https://developer.microsoft.com/en-us/windows/downloads/virt...

    • Com a licença gratuita QNX Everywhere, deve ser possível subir uma VM QEMU no IDE com alguns cliques
      Dito isso, entendo que seria mais fácil baixar com um clique, como nas imagens do Windows, e vou levar esse feedback
      Se eu puder ajudar de outra forma a viabilizar o suporte a QNX, mande uma DM ou escreva para qnxcommunityengagement at qnx dot com