Evernote kullanırken hizmetin aniden kötüleşmesi yüzünden bir ara OneNote'a taşınmıştım. O zamandan beri küçük şirketlerin not uygulamalarına mesafeli yaklaşıyorum. Çünkü Obsidian'ın politikası da bir anda değişebilir.
Bunu görünce bunu söylemiştim.
Gerçek zamanlı işlevler uzun süre çekirdekten ayrı bir proje olarak sürdürülebilmişti ve buna ihtiyaç duyanlar bunu alıp çekirdeğe uygulayarak kullanabiliyordu.
Ben de bir Rust kullanıcısıyım, ancak Rust kodu ile C kodu iç içe geçtiğinde, açık kaynakta Rust koduna ne ölçüde izin verileceğine dair çok sıkı kurallar olmadıkça bunun kontrol edilemez hâle geleceğini ya da en azından inceleme ve bakım maliyetini ciddi biçimde artıracağını düşünüyorum; bu yüzden ekleme yapmadan bir fork açmanın en akıllıca seçenek olduğu kanaatindeyim.
Sanırım kastedilen, çeşitli pazarlama yöntemleri arasında blogun en iyi seçenek olmadığı; ama alternatif olarak müşterinin ofisinin önünde pankartla tanıtım yapmak ya da X'te tartışmaya girmek önerilince bana pek öyle gelmiyor.
Çekirdek konusunda çok bilgili değilim ama C kodunu Rust'a otomatik çevirmek mümkün olsa güzel olurdu diye düşünüyorum. Elbette kod çevirisi sorununun yanı sıra insanlarla ilgili sorunlar da olacaktır.
Uzun vadede SEO'ya yatırım yapıp organik trafiği artırarak bununla istikrarlı gelir yaratan şirketleri biliyorum; buna katıldığım noktalar var ama buna gönülden tamamen katılmak zor.
Kernel geliştirme deneyiminiz olup olmadığını tam bilmediğim için ne söylemem gerektiğinden emin değilim.
Öncelikle, Rust dilini uygulamak demek çekirdeği Rust’a çevirelim demek değildir. Bunu ayırıp bir başka çekirdek daha yapsak olmaz mı diye sorabilirsiniz, ancak
amaç çekirdeği Rust ile yazmak değil; çekirdekte aygıt sürücüleri için yalnızca arayüzü Rust ile bir wrapper olarak hazırlayıp aygıt sürücülerinin sadece Rust ile
yazılabilmesini sağlayacak şekilde iyileştirme yapmayı önermektir. Bu yüzden yeni bir projeye gitmenin bir anlamı yoktur.
Küresel mühendisliğe dair romantik beklentilerden vazgeçmek gerekiyor..
Aşırı düzeyde süreç optimizasyonu gerekiyor ama tek bir yerel ölçekte 3 vardiyalı geliştirme oyun tarafında yaygındır.
Örneğin Çin’deki büyük oyun stüdyoları 24 saat, 3 vardiya halinde geliştirme yapıyor.
EA, Ubisoft gibi küresel mühendisliğin uzun süredir yerleşik olduğu oyun şirketleri, herkes kendi zaman dilimine göre çalıştığı için yürütme hızında gecikmelerin kaçınılmaz olduğunu kabul ediyor; ancak bunu düşük yaşam maliyeti + iş gücü maliyetinin telafi ettiği bir model gibi işletiyorlar. (Şu anda büyük çaplı yeniden yapılanmalar nedeniyle durumun nasıl olduğunu bilmiyorum.)
Çekirdek kararlılığı gerekçesiyle zehirli üslubu meşrulaştıragelen Linux topluluğunun, şimdi dönüp de "hoşuna gitmiyorsa fork'la" tepkisini makul bir yanıt sayması gerçekten ironik.
Evernote kullanırken hizmetin aniden kötüleşmesi yüzünden bir ara OneNote'a taşınmıştım. O zamandan beri küçük şirketlerin not uygulamalarına mesafeli yaklaşıyorum. Çünkü Obsidian'ın politikası da bir anda değişebilir.
Forklayıp ayrılsın denmesini hiç anlayamıyorum. Linus neden Linux'tan fork alıp ayrılsın ki?
Bunu görünce bunu söylemiştim.
Gerçek zamanlı işlevler uzun süre çekirdekten ayrı bir proje olarak sürdürülebilmişti ve buna ihtiyaç duyanlar bunu alıp çekirdeğe uygulayarak kullanabiliyordu.
Linux topluluğundan değilim ama...
Linux tarafında geliştirme yapmışlığım yok.
Aygıt sürücülerinin Rust wrapper'ları çekirdekten ayrılamayan bir yapıda sanırım...
O kişilerle bu yorumu yazan kişiyi aynı topluluk olarak görmememiz gerektiğini düşünüyorum.
Ben de bir Rust kullanıcısıyım, ancak Rust kodu ile C kodu iç içe geçtiğinde, açık kaynakta Rust koduna ne ölçüde izin verileceğine dair çok sıkı kurallar olmadıkça bunun kontrol edilemez hâle geleceğini ya da en azından inceleme ve bakım maliyetini ciddi biçimde artıracağını düşünüyorum; bu yüzden ekleme yapmadan bir fork açmanın en akıllıca seçenek olduğu kanaatindeyim.
Sanırım kastedilen, çeşitli pazarlama yöntemleri arasında blogun en iyi seçenek olmadığı; ama alternatif olarak müşterinin ofisinin önünde pankartla tanıtım yapmak ya da X'te tartışmaya girmek önerilince bana pek öyle gelmiyor.
Çekirdek konusunda çok bilgili değilim ama C kodunu Rust'a otomatik çevirmek mümkün olsa güzel olurdu diye düşünüyorum. Elbette kod çevirisi sorununun yanı sıra insanlarla ilgili sorunlar da olacaktır.
Şirkette kişisel olarak Obsidian kullanmayı denemek istemiştim ama lisans yüzünden vazgeçmiştim; sanırım tekrar denemeliyim.
Güzel...
Serbest çeviri sanmıştım.
Aa, ben ticari lisansla aboneydim; bu iyi olmuş.
Stable sürüme backport gerektiğinde ya da benzeri bir nedenle iletişime geçtiğimde, o kadar yoğunken bile çok iyi yanıt verdiğini hatırlıyorum.
Uzun vadede SEO'ya yatırım yapıp organik trafiği artırarak bununla istikrarlı gelir yaratan şirketleri biliyorum; buna katıldığım noktalar var ama buna gönülden tamamen katılmak zor.
Kernel geliştirme deneyiminiz olup olmadığını tam bilmediğim için ne söylemem gerektiğinden emin değilim.
Öncelikle, Rust dilini uygulamak demek çekirdeği Rust’a çevirelim demek değildir. Bunu ayırıp bir başka çekirdek daha yapsak olmaz mı diye sorabilirsiniz, ancak
amaç çekirdeği Rust ile yazmak değil; çekirdekte aygıt sürücüleri için yalnızca arayüzü Rust ile bir
wrapperolarak hazırlayıp aygıt sürücülerinin sadece Rust ileyazılabilmesini sağlayacak şekilde iyileştirme yapmayı önermektir. Bu yüzden yeni bir projeye gitmenin bir anlamı yoktur.
Ezici çoğunlukla GOTO videoları var gibi görünüyor..
Küresel mühendisliğe dair romantik beklentilerden vazgeçmek gerekiyor..
Aşırı düzeyde süreç optimizasyonu gerekiyor ama tek bir yerel ölçekte 3 vardiyalı geliştirme oyun tarafında yaygındır.
Örneğin Çin’deki büyük oyun stüdyoları 24 saat, 3 vardiya halinde geliştirme yapıyor.
EA, Ubisoft gibi küresel mühendisliğin uzun süredir yerleşik olduğu oyun şirketleri, herkes kendi zaman dilimine göre çalıştığı için yürütme hızında gecikmelerin kaçınılmaz olduğunu kabul ediyor; ancak bunu düşük yaşam maliyeti + iş gücü maliyetinin telafi ettiği bir model gibi işletiyorlar. (Şu anda büyük çaplı yeniden yapılanmalar nedeniyle durumun nasıl olduğunu bilmiyorum.)
Çekirdek kararlılığı gerekçesiyle zehirli üslubu meşrulaştıragelen Linux topluluğunun, şimdi dönüp de "hoşuna gitmiyorsa fork'la" tepkisini makul bir yanıt sayması gerçekten ironik.
> Başlık bunun kurallara yönelik bir eleştiri olduğunu belirtmeli
222